Unable to use backward mapping models created by index sets

[japaf]

I think this issue is connected to automatic initialization. As of now, it doesn't work for models created by index sets or models, which depend on them. Thus, I still use the old initModels. This runs fine, but creates func_* folders in the root directory. When the workflow is run, it re-compiles the surrogate model for some reason once again, this time inside one of the launcher_* directories. It seems to initialize the first of the index sets models, but fails for the second one.

How to reproduce:

• go to my solub branch
• go to foamAging application
• ./build
• prepare input file, e.g., cp example_inputs/foamAging.in . and change line 16 to 1 1 1
• ./initModels
• ./workflow

Error message:

Performing backward mapping simulation (macroscopic code recipe)
Loading model solubilityPol[A=CO2] failed - Attempting automatic initialisation
modena.Strategy.ParametersNotValid: ('Surrogate model does not have valid parameters', <BackwardMappingModel: BackwardMappingModel object>)
Error in python catched in 226 of /home/pavel/github/MoDeNa/src/src/model.c
/home/pavel/lib/modena/libmodena.so.1(modena_print_backtrace+0x1a) [0x7f64f769994a]
/home/pavel/lib/modena/libmodena.so.1(modena_model_new+0x123) [0x7f64f769ae53]
/home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas(__physicalproperties_MOD_createmodels+0x3e2) [0x455b92]
/home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas() [0x45711f]
/home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas(_start+0) [0x40429d]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f64f6abcec5]
/home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas() [0x4042c6]
return code = 1
An unknow error occurred
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/fireworks/core/rocket.py", line 211, in run
    m_action = t.run_task(my_spec)
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1040, in run_task
    self.task(fw_spec)
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1096, in task
    self.handleReturnCode(ret.stored_data['returncode'])
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1079, in handleReturnCode
    sys.exit(returnCode)
SystemExit: 1
2016-02-11 10:56:28,262 INFO Rocket finished
Segmentation fault

[sigveka]

Pavel,

I will have a look at your branch later today.

In the mean time, have you remembered to add:

indices={ 'A': species, 'B': species, },

to your surrogate function (CFunction)?

Regards,

Sigve ​

On 11 February 2016 at 10:59, Pavel Ferkl notifications@github.com wrote:

I think this issue is connected to automatic initialization. As of now, it doesn't work for models created by index sets or models, which depend on them. Thus, I still use the old initModels. This runs fine, but creates func* folders in the root directory. When the workflow is run, it re-compiles the surrogate model for some reason once again, this time inside one of the launcher* directories. It seems to initialize the first of the index sets models, but fails for the second one.

How to reproduce:

• go to my solub branch
• go to foamAging application
• ./build
• prepare input file, e.g., cp example_inputs/foamAging.in . and change line 16 to 1 1 1
• ./initModels
• ./workflow

Error message:

Performing backward mapping simulation (macroscopic code recipe) Loading model solubilityPol[A=CO2] failed - Attempting automatic initialisation modena.Strategy.ParametersNotValid: ('Surrogate model does not have valid parameters', ) Error in python catched in 226 of /home/pavel/github/MoDeNa/src/src/model.c /home/pavel/lib/modena/libmodena.so.1(modena_print_backtrace+0x1a) [0x7f64f769994a] /home/pavel/lib/modena/libmodena.so.1(modena_model_new+0x123) [0x7f64f769ae53] /home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas(physicalproperties_MOD_createmodels+0x3e2) [0x455b92] /home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas() [0x45711f] /home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas(_start+0) [0x40429d] /lib/x86_64-linux-gnu/libc.so.6(libc_start_main+0xf5) [0x7f64f6abcec5] /home/pavel/github/MoDeNa/applications/PUfoam/MoDeNaModels/foamAging/src/degas() [0x4042c6] return code = 1 An unknow error occurred Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/fireworks/core/rocket.py", line 211, in run m_action = t.run_task(my_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1040, in run_task self.task(fw_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1096, in task self.handleReturnCode(ret.stored_data['returncode']) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1079, in handleReturnCode sys.exit(returnCode) SystemExit: 1 2016-02-11 10:56:28,262 INFO Rocket finished Segmentation fault

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73.

[japaf]

Hello Sigve, thanks for helping. The indices are specified. The incriminated file is this one: https://github.com/japaf/MoDeNa/blob/solub/applications/PUfoam/MoDeNaModels/Solubility/Solubility.py

[sigveka]

Pavel,

I am having problems compiling “Solubility” (in your branch, Henrik’s branch works fine)

Have you seen this error?

[ 2%] Building Fortran object CMakeFiles/PCSAFT_Henry.dir/matrix_inversion-aux.f90.o /home/sigveka/Desktop/pavel/MoDeNa/applications/PUfoam/MoDeNaModels/Solubility/src/matrix_inversion-aux.f90:30.16:

betrag=dabs(vektor(i))
            1

Error: 'a' argument of 'dabs' intrinsic at (1) must be double precision CMakeFiles/PCSAFT_Henry.dir/build.make:279: recipe for target 'CMakeFiles/PCSAFT_Henry.dir/matrix_inversion-aux.f90.o' failed make[2]: * [CMakeFiles/PCSAFT_Henry.dir/matrix_inversion-aux.f90.o] Error 1 CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/PCSAFT_Henry.dir/all' failed make[1]: * [CMakeFiles/PCSAFT_Henry.dir/all] Error 2 Makefile:76: recipe for target 'all' failed make: *\ [all] Error 2

With regards to your problem I believe I have identified the cause. It is fixable, but requires some coding!

Regards,

Sigve ​

On 11 February 2016 at 14:12, Pavel Ferkl notifications@github.com wrote:

Hello Sigve, thanks for helping. The indices are specified. The incriminated file is this one:

https://github.com/japaf/MoDeNa/blob/solub/applications/PUfoam/MoDeNaModels/Solubility/Solubility.py

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-182857922 .

[japaf]

Sigve, I updated the model of Jonas. PCSAFT_Henry is no longer build. Moreover, Jonas told me he doesn't use cmake so Solubility is not build by cmake in this version. Could you please delete all cmake files from your Solubility folder and then pull from me again. I recently pushed the manually prepared Makefile, which is now used. That should fix the problem. Pavel

[sigveka]

A quick solution for you to fix the problem is to do the following:

Replace line 206 in model.c

With the following line:

if(PyErr_ExceptionMatches(modena_DoesNotExist) || PyErr_ExceptionMatches(modena_ParametersNotValid) )

The surrogate function will still be compiled into the “launcher”

directory, but I will work on that!

I am trying to figure out the best way to compile your complex applications, maybe I can have you write the commands to compile the source codes into the definition of the surrogate model(?)

Sigve ​

On 12 February 2016 at 14:36, Pavel Ferkl notifications@github.com wrote:

Sigve, I updated the model of Jonas. PCSAFT_Henry is no longer build. Moreover, Jonas told me he doesn't use cmake so Solubility is not build by cmake in this version. Could you please delete all cmake files from your Solubility folder and then pull from me again. I recently pushed the manually prepared Makefile, which is now used. That should fix the problem. Pavel

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-183332247 .

[sigveka]

I am afraid I was lying to you about a “quick fix”.

It will fix the error message you are getting, only to trigger a new error; hence, I have to do some more “background magic” for it to work.

The reason is that we are importing the python module for the surrogate model using the _id field.

Consider the following model _id:

MyModel[A=hexane,B=toluene]

I am then trying to do the equivalent of import MyModel. In the case of the Solubility model the _id does not match the module name.

This can be fixed, but I need to think a little bit before I hammer out the code.

Regards,

Sigve ​

On 12 February 2016 at 15:02, Sigve Karolius sigveka@gmail.com wrote:

A quick solution for you to fix the problem is to do the following:

Replace line 206 in model.c

With the following line:

if(PyErr_ExceptionMatches(modena_DoesNotExist) || PyErr_ExceptionMatches(modena_ParametersNotValid) )

The surrogate function will still be compiled into the “launcher”

directory, but I will work on that!

I am trying to figure out the best way to compile your complex applications, maybe I can have you write the commands to compile the source codes into the definition of the surrogate model(?)

Sigve ​

On 12 February 2016 at 14:36, Pavel Ferkl notifications@github.com wrote:

Sigve, I updated the model of Jonas. PCSAFT_Henry is no longer build. Moreover, Jonas told me he doesn't use cmake so Solubility is not build by cmake in this version. Could you please delete all cmake files from your Solubility folder and then pull from me again. I recently pushed the manually prepared Makefile, which is now used. That should fix the problem. Pavel

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-183332247 .

[japaf]

I just wanted to write to you. So anyway, thanks for looking into this.

@(compilation of complex models): I don't think that maintaining some "build" script for each application like we are doing now is that much of a hassle. However, I agree that having this information close to the model would be more logical and it would scale better if one model is used in a number of applications. Maybe somewhere in the FireTaskBase would be the best place?

[sigveka]

No problem, that is what I am here for.

Side note: You will see (in nextRelease) that FireTaskBase is replaced by ModenaFireTask (minor edits required from your point of view).

That is certainly one possibility, the issue I have is that the exact simulation class is instantiated every time the simulation is performed, and I do not want to check whether the application is compiled every time we are executing it. Instead I would prefer to check that the application is compiled only when the surrogate model is loaded from the database, but I will take this up with Henrik.

Sigve ​

On 12 February 2016 at 15:36, Pavel Ferkl notifications@github.com wrote:

I just wanted to write to you. So anyway, thanks for looking into this.

@(compilation of complex models): I don't think that maintaining some "build" script for each application like we are doing now is that much of a hassle. However, I agree that having this information close to the model would be more logical and it would scale better if one model is used in a number of applications. Maybe somewhere in the FireTaskBase would be the best place?

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-183354499 .

[japaf]

74 fixed the problem:

modena.Strategy.ParametersNotValid: ('Surrogate model does not have valid parameters', <BackwardMappingModel: BackwardMappingModel object>)

However, when the model is out of range, the program ends with:

Performing backward mapping simulation (macroscopic code recipe)
Loading model solubilityPol[A=CO2] failed - Attempting automatic initialisation

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7F655832C777
#1  0x7F655832CD7E
#2  0x7F6557A68D3F
#3  0x7F6558630833
#4  0x455C00 in __physicalproperties_MOD_createmodels
#5  0x45723E in MAIN__ at main.f90:?
Segmentation fault
return code = 139
An unknow error occurred
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/fireworks/core/rocket.py", line 211, in run
    m_action = t.run_task(my_spec)
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1047, in run_task
    self.task(fw_spec)
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1103, in task
    self.handleReturnCode(ret.stored_data['returncode'])
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1086, in handleReturnCode
    sys.exit(returnCode)
SystemExit: 139
2016-02-15 09:42:57,669 INFO Rocket finished
Segmentation fault

I realized that I can use the solubility model if I initialize with broad enough range of initial points, but I leave the issue open.

[sigveka]

I am picking it up right away!

only tested the fix on the examples, this is aparently a little more involved...

Sigve

On 15 February 2016 at 09:55, Pavel Ferkl notifications@github.com wrote:

74 https://github.com/MoDeNa-EUProject/MoDeNa/pull/74 fixed the

problem:

modena.Strategy.ParametersNotValid: ('Surrogate model does not have valid parameters', )

However, when the model is out of range, the program ends with:

Performing backward mapping simulation (macroscopic code recipe) Loading model solubilityPol[A=CO2] failed - Attempting automatic initialisation

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

0 0x7F655832C777

1 0x7F655832CD7E

2 0x7F6557A68D3F

3 0x7F6558630833

4 0x455C00 in **physicalproperties_MOD_createmodels

5 0x45723E in MAIN** at main.f90:?

Segmentation fault return code = 139 An unknow error occurred Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/fireworks/core/rocket.py", line 211, in run m_action = t.run_task(my_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1047, in run_task self.task(fw_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1103, in task self.handleReturnCode(ret.stored_data['returncode']) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1086, in handleReturnCode sys.exit(returnCode) SystemExit: 139 2016-02-15 09:42:57,669 INFO Rocket finished Segmentation fault

I realized that I can use the solubility model if I initialize with broad enough range of initial points, but I leave the issue open.

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-184119671 .

[sigveka]

Mr Ferkl,

I do not think you have implemented a check to see whether your model was instantiated correctly, i.e. after modena_model_new.

e.g.

model = modena_model_new(c_char"awesome_model"//c_null_char);

if(modena_error_occurred()) then call exit(modena_error()); endif

I hope this works for you,

Sigve

NOTE

Sorry for repeating myself, but in order for this to work the python module must have the same name as the _id field of the surrogate model. This is not the case in “Solubility” at the moment, where the module is called “Solubility”, and the surrogate models are called “solubilityPol”. ​

On 15 February 2016 at 10:22, Sigve Karolius sigveka@gmail.com wrote:

I am picking it up right away!

only tested the fix on the examples, this is aparently a little more involved...

Sigve

On 15 February 2016 at 09:55, Pavel Ferkl notifications@github.com wrote:

74 https://github.com/MoDeNa-EUProject/MoDeNa/pull/74 fixed the

problem:

modena.Strategy.ParametersNotValid: ('Surrogate model does not have valid parameters', )

However, when the model is out of range, the program ends with:

Performing backward mapping simulation (macroscopic code recipe) Loading model solubilityPol[A=CO2] failed - Attempting automatic initialisation

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:

0 0x7F655832C777

1 0x7F655832CD7E

2 0x7F6557A68D3F

3 0x7F6558630833

4 0x455C00 in **physicalproperties_MOD_createmodels

5 0x45723E in MAIN** at main.f90:?

Segmentation fault return code = 139 An unknow error occurred Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/fireworks/core/rocket.py", line 211, in run m_action = t.run_task(my_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1047, in run_task self.task(fw_spec) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1103, in task self.handleReturnCode(ret.stored_data['returncode']) File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 1086, in handleReturnCode sys.exit(returnCode) SystemExit: 139 2016-02-15 09:42:57,669 INFO Rocket finished Segmentation fault

I realized that I can use the solubility model if I initialize with broad enough range of initial points, but I leave the issue open.

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-184119671 .

[japaf]

Hello Sigve,

You are right these checks are largely missing in my code. Sorry about that. I will try to improve that.

I must have read the passage about _id wrongly. I thought you were talking about the difference between "solubilityPol[A=Air]" and "solubilityPol" and that more needs to be done for this special issue.

I renamed surrogate models to "Solubility[A=*]" and implemented the checks. The output I am getting now is:

Performing backward mapping simulation (macroscopic code recipe)
Loading model Solubility[A=CO2] failed - Attempting automatic initialisation
return code = 201
Could not find MoDeNa model 'Solubility[A=CO2]'
Model not initialised, executing initialisationStrategy
Traceback (most recent call last):
  File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 961, in parametersNotValid
    wf = model.initialisationStrategy().workflow(model)
AttributeError: 'NoneType' object has no attribute 'initialisationStrategy'
2016-02-16 10:40:54,649 INFO Task completed: {{modena.Strategy.BackwardMappingScriptTask}} 
2016-02-16 10:40:54,692 INFO Rocket finished
Segmentation fault

Note that this is not high priority, because I can use the model as is, just the backward mapping feature is not working.

Pavel

[sigveka]

No worries, just making sure we are on the same page.

This error message is coming from me, so I will look at it.

Sigve

On a side note:

I have a few thoughts regarding naming, and how we cooperate and communicate. Maybe you have input, and/or can help me carry out the message to the rest. However, bare in mind that I am known to overreach my limitations when I start philosophizing…

The situation we are in now captures the essence of the cooperation/communication in this project, or any other interdisciplinary project for that matter.

When an author of a module change the _id of a surrogate model he/she/it must also notify everyone using that model that the _id has changed. The reason for this is that the source code of the detailed applications employing that surrogate model must be modified and the re-compiled. In other words, by changing the name of the Solubility surrogate models you are affecting all the other applications using it.

However, you can change the module name, in which case the source code of the detailed applications does not require any adaptation, but any import statement, e.g. in conjunction with “substitute models”, must be modified accordingly.

So, how do we deal with this? I propose:

1. Any changes to a module must happen in collaboration with the author of the module.
2. The author should know who is using it, and make sure that they do not object to the changes (e.g. if we do not have access to the source code of an application it is not advisable to change the _id …)
3. Ultimately, it is the responsibility of the author of a module to carry out, or at least approve, any changes, and that README files etc. are up-to date.

I am not saying it is wrong to change the _id, in this case I am inclined to agree, but the interdisciplinary nature of the project demands that we also work towards understanding, and getting an intuition about the link between our fields. In this sense, changing the _id may provoke a discussion between partners about how models on the respective scales relate to and compliment each other, which can be positive for both partners. ​

On 16 February 2016 at 11:47, Pavel Ferkl notifications@github.com wrote:

Hello Sigve,

You are right these checks are largely missing in my code. Sorry about that. I will try to improve that.

I must have read the passage about _id wrongly. I thought you were talking about the difference between "solubilityPol[A=Air]" and "solubilityPol" and that more needs to be done for this special issue.

I renamed surrogate models to "Solubility[A=*]" and implemented the checks. The output I am getting now is:

Performing backward mapping simulation (macroscopic code recipe) Loading model Solubility[A=CO2] failed - Attempting automatic initialisation return code = 201 Could not find MoDeNa model 'Solubility[A=CO2]' Model not initialised, executing initialisationStrategy Traceback (most recent call last): File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 961, in parametersNotValid wf = model.initialisationStrategy().workflow(model) AttributeError: 'NoneType' object has no attribute 'initialisationStrategy' 2016-02-16 10:40:54,649 INFO Task completed: {{modena.Strategy.BackwardMappingScriptTask}} 2016-02-16 10:40:54,692 INFO Rocket finished Segmentation fault

Note that this is not high priority, because I can use the model as is, just the backward mapping feature is not working.

Pavel

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-184622081 .

[sigveka]

Did you push the latest changes?

There were some updates when I pulled. but I am still getting the "old" error...

On 16 February 2016 at 12:59, Sigve Karolius sigveka@gmail.com wrote:

No worries, just making sure we are on the same page.

This error message is coming from me, so I will look at it.

Sigve

On a side note:

I have a few thoughts regarding naming, and how we cooperate and communicate. Maybe you have input, and/or can help me carry out the message to the rest. However, bare in mind that I am known to overreach my limitations when I start philosophizing…

The situation we are in now captures the essence of the cooperation/communication in this project, or any other interdisciplinary project for that matter.

When an author of a module change the _id of a surrogate model he/she/it must also notify everyone using that model that the _id has changed. The reason for this is that the source code of the detailed applications employing that surrogate model must be modified and the re-compiled. In other words, by changing the name of the Solubility surrogate models you are affecting all the other applications using it.

However, you can change the module name, in which case the source code of the detailed applications does not require any adaptation, but any import statement, e.g. in conjunction with “substitute models”, must be modified accordingly.

So, how do we deal with this? I propose:

1. Any changes to a module must happen in collaboration with the author of the module.
2. The author should know who is using it, and make sure that they do not object to the changes (e.g. if we do not have access to the source code of an application it is not advisable to change the _id …)
3. Ultimately, it is the responsibility of the author of a module to carry out, or at least approve, any changes, and that README files etc. are up-to date.

I am not saying it is wrong to change the _id, in this case I am inclined to agree, but the interdisciplinary nature of the project demands that we also work towards understanding, and getting an intuition about the link between our fields. In this sense, changing the _id may provoke a discussion between partners about how models on the respective scales relate to and compliment each other, which can be positive for both partners. ​

On 16 February 2016 at 11:47, Pavel Ferkl notifications@github.com wrote:

Hello Sigve,

You are right these checks are largely missing in my code. Sorry about that. I will try to improve that.

I must have read the passage about _id wrongly. I thought you were talking about the difference between "solubilityPol[A=Air]" and "solubilityPol" and that more needs to be done for this special issue.

I renamed surrogate models to "Solubility[A=*]" and implemented the checks. The output I am getting now is:

Performing backward mapping simulation (macroscopic code recipe) Loading model Solubility[A=CO2] failed - Attempting automatic initialisation return code = 201 Could not find MoDeNa model 'Solubility[A=CO2]' Model not initialised, executing initialisationStrategy Traceback (most recent call last): File "/home/pavel/lib/python2.7/site-packages/modena/Strategy.py", line 961, in parametersNotValid wf = model.initialisationStrategy().workflow(model) AttributeError: 'NoneType' object has no attribute 'initialisationStrategy' 2016-02-16 10:40:54,649 INFO Task completed: {{modena.Strategy.BackwardMappingScriptTask}} 2016-02-16 10:40:54,692 INFO Rocket finished Segmentation fault

Note that this is not high priority, because I can use the model as is, just the backward mapping feature is not working.

Pavel

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-184622081 .

[japaf]

There should be no segmentation fault on the latest commit (e3063fa64ce77205ed9068eb20ad994ed0fa5788). Branch is still solub. You need to do ./build, ./initModels and ./workflow again.

[sigveka]

I am on the same commit, but physicalProperties.f90 in “foamConductivity” has not implemented the error check. However, the _id of Solubility is changed. ​

On 16 February 2016 at 17:14, Pavel Ferkl notifications@github.com wrote:

There should be no segmentation fault on the latest commit (e3063fa https://github.com/MoDeNa-EUProject/MoDeNa/commit/e3063fa64ce77205ed9068eb20ad994ed0fa5788). Branch is still solub.

— Reply to this email directly or view it on GitHub https://github.com/MoDeNa-EUProject/MoDeNa/issues/73#issuecomment-184750079 .

[japaf]

Maybe it's only a typo, but the relevant physicalProperties.f90 is in "foamAging" (https://github.com/japaf/MoDeNa/blob/solub/applications/PUfoam/MoDeNaModels/foamAging/src/src/physicalProperties.f90). I did not implement the checks everywhere, just for solubility now. One of them is on lines 145-147:

if (modena_error_occurred()) then
    call exit(modena_error())
endif