Not ROSMOSE recommended anymore

The framework is not recommended anymore to use Rosmose platform. PinchSmall is expected to deprecate the R use and the pyxosmose monolithic approach.

Where can I find the database of documented models of @wen du and @pietrodavi? To my best knowledge, I have not seen a significant contribution from these team members to any dimension, task or realization of PinchSmall.

Where can we find the 1 year long development cost database of @wen du?

At this pace, I will complete this functionality with the help of Mathilde and Henrique from IST via IETS.

not yet implemented (trying to integrate the incomplete discussions of Arthur Waeber and Cyrille on multiperiod and storage systems - vide issues open in pyxosmose)

??

A unit cannot have other units. By definition, we have sets of units in a model, and models that can be clustered. If a unit is added to a unit that is added to a unit, another modelling approach than OSMOSE must be implemented. On the other hand, if only units are intended, then the current ET or Model approach needs to be considered merely cosmetic. The discussion about the folder in folders and the hierarchy of units have been discussed.

yep, we discussed this. Awaiting to see the UX for this

Rosmose should start being deprecated. It is blackboxed and rigid for implementing all the OSMOSE functionalities.

Unfinished

the part that is not properly addressed/understood and, personally, timely feasible is the " system data, results interpretation, etc" in real time by "the bot", for which we discussed with @lorenzo to try to adapt his student's work on LLMs. If bot requires a specific task till October 24 demonstration, it should be addressed from now.

This part is currently less discussed, but it is one of the most important problems to solve for pinchsmall/osmose users, even though it looks like a trivial question. In the GUI of Cyrille, all the configuration files were saved, model params, results, annotations, logfiles, etc. This is coherent with the other software packages out there.

In the current validated idea, PinchSmall is composed of a UI/UX that helps guiding the context and system definition, as well as the selection of the process and technologies to be included in the problem. Finally, a section for definition of the "frontend" settings, to next navigate into the database of reporting plots/tables and the selection of the type of report. It must generate QMDs that allows the user to write the report. The latest request to IT is the possibility to render a report that, when required, can be modified in a form of "what you write is what you see", never revealing the code-like qmd language to an average user.

The only part that is not properly implemented is the " system data, results interpretation,etc", which I discussed with Lorenzo Aimone to try to adapt his student work on LLMs, but it seems to require a dedicated task till October 24 demonstration. Please verify with Lorenzo this task.

No visual studio for the MVP

? Tiles? Tabs?

I disagree with the definition of disorder :D I prefer "number of statistical states"

Avoid too much in depth subfolderization

favor the strategy of horizontal classification

Project --> Models --> Subprocess (Units) --> Units operations (rs, qt).

prefer use of clusters, location, restrictions, heat cascades

Process, units (subprocess), units operations.

the use of r, s, F, P, w, e, makes complicated to define the mass balances.

It should be only specified the mass balance of each flow as m (with m being r, s, F, P, w, e, etc)

In the figure below, there should not be an inlet \(\dot M_{P}^{+}(\pi_{u})\) as "material layer processes", but feedstock \(\dot M_{F}^{+}(\pi_{u})\)

There should not be \(\dot{m}^+{r,i} = \digamma{u,i} (\pi_{u},S_{u}^{},\dot{m}^{+,x}{r,i}) \) but \(\dot{m}^+{m,i} = \digamma_{u,i} (\pi_{u},S_{u}^{},\dot{m}^{+,x}_{m,i}) \) to avoid confusing with only mass balance for support, energy and waste but also environment flow, products and feedstock (see mass balance equation below)

• process: Industrial process
• unit: closer to subprocess and composed of "unit operations".
• model: contains subprocesses or "units"

All three words are used for describing different entities. In this figure, it seems to represent a subprocess or "unit" which can have instances that feature different interfaces (each set of interfaces define one subprocess or units, and the interfaces of those units are given by the "internal" unit operations)

If they are a set of equations, now it is impossible to know when it starts and when it ends each of them, I assume the second equation starts at fmin,u and finish at fmax,u

The existence of diverse interfaces i for the process unit u should imply rather a different version of u (an instantiation). Otherwise it seems that one single unit may have a mixture of different interfaces, while the reality is that each instance of this unit should be "one different unit" with different governing equations and interfaces.

For instance, in OSMOSE we do not mutually exclude Streams but Units, and this prevents having Units with different mixtures of streams types.

Connectivity interfaces means "connectors characterized by states"

Physical and thermodynamic model

(in contrast to a input-output black box. It holds the governing equations given by mass and energy balances, together with design parameters --> properties correlations, physical limitations, derived magnitudes, etc.)

This division implies a difference between the conversion and the process units, while they are essentially the same. The process units process the flows (connection streams) that are converted inside the unit (nodes)

?

This is a description of the full problem definition, integration and reporting. It is not a working package itself.

?? Does it mean the fetching/parsing/display/database management and webapp deployment? This assignment is not clear.

Should not it be at the very beginning?

**?

Broken or purposely non-existing link

Instead of process unit database, should not be named utility technologies/energy technologies/decarbonization technologies database?

Process units make reference to a set of operation units of any (industrial) process and it can be misleading if not differentiated from the industrial processes database.

Does it mean that we need to instantiate variables for different models, instead of adding the variables directly to the specified models?

That would pose problems of scope if not well treated.

typo?

Variables will be stored in a dictionary with all the fields available for consulting.

Not human readable, For instance, What is property A - B = 25?

Various uses of colons (:) for inline definitions, key:value definitions, osmose chunk definition are not intuitive. We should remove the use of colons whenever not necessary.

This is a python formatting code. Not clear for users not familiar with python.

This definitely requires a warning, but an error message will make the process more complicated, since a priori all the composed ranges (derived from combined ranges of primary variables) will be too complicated to predict, especially for models that are initially unknown

The < and << equivalence for values definition ftis better in the frontend definition, when passing the context, the general params and the other multiperiodic variables. Variables definition as entities is done in the model definition, but not the source. The CSV file is data definition for other operating conditions.

This should be only addressed by a master SOBOL/Montecarle sequence definition, and not inside of the variable definition.

Does it mean that the definition of the source of the variable and the definition of the variable are both used in all the cases? Should not only the variable definition be maintained and the source specified as @ source and that is it?

o

typo

?

typo

For some reason (maybe ASCII or UTF-8 config), the CSV file is displaying strange characters.

my_variable1,10,100,25,°C,T_in,T_{in},Inlet temperature conditions,@ source

I would suggest dropping the special characters for the celsius and fahrenheit.

Dictionary in JSON

here, the use of _ offers no clear separation for the variable names or the lower bound definition. The user will not use this notation to input data

Considering the web based tool, the inline definition of variables seems to be more cumbersome, unless using a form filling approach (which is monolithic). I would favor the use of csv files.

This should not be presented to any author, unless for debugging purposes (verbose).

Must not be used in the template or presented to the user anywhere.

Same comment here for the use of : ... :

better to avoid the use of difficult to catch typing errors.

I would drop any convention to use underscores, hashtags, circunflexes, square or rounded brackets if it is not for a machine dealing with regular expressions.

Many of the debugging problems of ROSMOSE stem from the difficulty of finding inconsistences in #$%^}] or lacking/mistaken symbols

Does it mean the multiperiod (table) definition of the variable?

Or the default value?

Or a calculated value from other variables?

Not clear, doest it mean

myvar: as a key of a dictionary? Does it work as the name of the variable (mathematically) as well?

Should have a variable name and a full name (different from a description). The full name is equivalent to the display name for draw io representations

We should call them Variables, Engineering variables etc. Not tags. Tags are more categories used in browsing content.

To be populated by the 60% in-kind contribution of the PinchSmall project. It should follow the provided templates (spreadsheet).

• How to categorize these different "industrial sectors"?

• Show the industrial sectors have a set of equipment that are repeated for the different sector actitivies?

• Should not rather be categorized by unit operations and functionality, instead of economic activity?

Currently, all the costs are dumped into a "industrial sector 2" without any detail of the calculation procedure, most current suggested CEPCI, etc

achieve, carry out, perform, attain

ROSMOSE syntax may depend on the continuity of pyxosmose or a new approach to define chunks as pure python chunks

flows values models?

typo

of the use

typo

Capital case

Sounds like a doc-ing attempt

typo

Not clear