Unable to use backward mapping models created by index sets

Question

Unable to use backward mapping models created by index sets

Closed this issue 8 years ago · 17 comments

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

Answer 1 · 2016-02-11T12:21:50.000Z

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', <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

—
Reply to this email directly or view it on GitHub
#73.

Answer 2 · 2016-02-11T13:12:03.000Z

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

Answer 3 · 2016-02-12T13:21:37.000Z

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
#73 (comment)
.

Answer 4 · 2016-02-12T13:36:47.000Z

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

Answer 5 · 2016-02-12T14:02:07.000Z

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
#73 (comment)
.

Answer 6 · 2016-02-12T14:23:09.000Z

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
#73 (comment)
.

Answer 7 · 2016-02-12T14:36:35.000Z

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?

Answer 8 · 2016-02-12T14:44:20.000Z

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
#73 (comment)
.

Answer 9 · 2016-02-15T08:55:41.000Z

#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.

Answer 10 · 2016-02-15T09:22:23.000Z

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 #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.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

Answer 11 · 2016-02-15T14:49:06.000Z

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 #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.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

Answer 12 · 2016-02-16T10:47:29.000Z

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

Answer 13 · 2016-02-16T11:59:43.000Z

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:

Any changes to a module must happen in collaboration with the author
of the module.
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 …)
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
#73 (comment)
.

Answer 14 · 2016-02-16T15:52:56.000Z

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:

Any changes to a module must happen in collaboration with the
author of the module.

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 …)

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
#73 (comment)
.

Answer 15 · 2016-02-16T16:14:12.000Z

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

Answer 16 · 2016-02-16T16:23:18.000Z

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
e3063fa).
Branch is still solub.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

Answer 17 · 2016-02-16T16:36:04.000Z

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