Closed japaf closed 8 years ago
@1) Initialisation (and compilation) can be deferred to the time when the model is actually used from within the macroscopic code. An example is in example/twoTanksAutoInit. This is fully automatic (ie. no initialisation on the outside is required), but the macroscopic code would stop on every call to a 'new' model. We can add additional functions to the interface library if this becomes a problem @2) Yes, you need to import the solubility model @3) Not sure what you mean here: Shouldn't we all use SI units?
foamAgeing
and foamConductivity
becomes "models" that are both imported into an application. The nice thing about Fireworks is that it executes the programs/scripts in one directory; therefore you do not have to think about where to pick up "input/output" files only agree on the structure. (I have not understood how this works with distributed computing.)workflow
using import US_Solubility_Model
.
applications
, models
, examples
, src
, Readme.md
. Objections?@1) I am talking about compiling Fortran/C against the interface library. Distributed computing is a complex matter. @2) Hmm. I think I would like to keep the PUFoam self-contained and avoid mixing the models from examples and applications. How about
applications/PUFoam/PUFoam0D/0D_code.C applications/PUFoam/PUFoam3D/3D_code.C applications/PUFoam/models examples/twoTanks examples/twoTanksAutoInit examples/models src
In order to avoid setting PYTHON_PATH we could simple walk down the tree and search all model directories we can find.
@3) dL is not SI
@1) I was talking about the detailed model. Sorry for the confusion. I wanted to do cmake .
and make
only in the application I want to use. Having to explain in README of foamAgeing that if they want to use PC SAFT model they need to go to different folder, open a README there and find out how to compile it seems unnecessarily complicated to me.
@2) Breaking down foamAgeing into individual models makes sense to me. I am not sure about the best structure. My idea is following:
applications/PUFoam/models
would contain folders with detailed models of foamConductivity
, foamAgeing
, PC_SAFT_Solubility
, etc.applications/PUFoam/workflows
would contain what we have as "applications" now, i.e., foamAgeing
and foamingProcess
. All python scripts would still be there. Theoretically, python model modules like foamConductivity.py
can be also moved to models folder. However, I think that these files are still application-specific. For example, even though both foamAgeing and foamingProcess would eventually contain very similar solubility.py
file, we might want to initialize solubility for different species etc.Ordinary user would interact only with workflows folder (changing input files, running simulations and looking at results).
@3) This is a long standing issue between me and Jonas about the definition of solubility. This was mentioned only for completeness. It can be fixed once the models are communicating.
On 30 September 2015 at 12:15, Henrik Rusche notifications@github.com wrote:
@1 https://github.com/1) I am talking about compiling Fortran/C against the interface library. Distributed computing is a complex matter. @2 https://github.com/2) Hmm. I think I would like to keep the PUFoam self-contained and avoid mixing the models from examples and applications. How about applications/PUFoam0D/0D_code.C applications/PUFoam3D/3D_code.C applications/PUFoam/models examples/twoTanks examples/twoTanksAutoInit examples/models src
In order to avoid setting PYTHON_PATH we could simple walk down the tree and search all model directories we can find.
@3 https://github.com/3) dL is not SI
— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/25#issuecomment-144347165 .
@1) compilation now works from foamAging through ./build
script. I didn't manage to use the makefile
provided by Jonas, so I added some necessary CMake files. There are two copies of PC_SAFT. I use the code from PythonModule_and_DetailedModelCode/DetailedModelCode
. Is this correct?
@2) I copied and modified modSolubility.py
one folder up, so that __init__.py
can see it. I used index sets to create the desired models. However, I still have few issues with that.
@3) I don't think that molar mass of PU will be part of the recipe. It is rather a PC_SAFT parameter. Consequently, the foamAging model will not know this value. I think we have two options:
Personally, I think the first option is better.
@1) Yes, this is the correct code. However, I cant think of a reason why the makefile shouldnt work. If you open it, you will find that it doesnt contain much that could go wrong. On the other hand, if it works with cmake now, thats better anyway.
@2) You are right, I will have to add composition as an additional input argument to the surrogate model. Assuming it to be constant during the simulation would be too much of a simplification. Regarding the convergence of PC-SAFT, yes, unfortunately this happens and there is no quick fix for it.
@3) Both way are possible, we should discuss this next week at the meeting in more detail.
If I am correct, several things need to done.