[philippose]

Hello everybody,
A Good day to you all... Looks like winter has decided to step into my part of the world :-O Was greeted / threatened by a thin white veil this morning.

So, here is the current problem I am facing...:

Basic Info:
* OpenFOAM v1606+
* simpleFoam
* swak4Foam - latest mercurial commit along with patches for v1606+
* decomposed simulation
* multiple boundary conditions defined using groovyBC

Scenario:
* Need to use storedVariables in one of the boundary conditions to accumulate values.
* Everything works fine when running the simulation using one processor core (serial simulation).
* Segmentation Fault when running in parallel during the first "write to disk" iteration.

What I have figured out so far:
* Problem arises only when a patch defined using groovyBC has storedVariables.
* Problem arises only when after decomposition, the patch with the storedVariables has "0" faces in any of the processors.
* After adding "flush()" to each of the write operations in the "ExpressionResult operator<<" function, it is clear that the error occurs when trying to access the "value" entry of the storedExpressionResult object for the patch on the processor containing "0" faces.
* When using "debugCommonDriver", the simulation crashes at the start of "Time 1", when it tries to write out the result of the variable evaluation of the sortedVariable on the patch containing "0" faces.
* I have tried this also on foam-extend-3.2, and the same error occurs here too. So it is not isolated to just v1606+.
* During the decomposePar operation, the fields are written fine (groovyBC sets the fieldSize of the storedVariable to "0" and writes a "nonuniform 0()" entry for the "value"). The error occurs only during the first write operation during the solver run.

What I think:
* Looks like the "valPtr_" variable points to an invalid address for patches which have "0" faces.
* But, I am not sure yet at which point this happens, and why it happens (specially because it seems like a "fieldSize" of zero does not get any special treatment anywhere in the code).

Questions:
* Is this a known issue? (have found one reference to this on the forum, but nothing in the bug list)
* What could be a plausible solution? I tried a lot of temporary code changes, but came up with no working solution.

@Bernhard... would it be possible for you to help me out on this front? Over the last week or so, this has become a show-stopper for a couple of cases I am working on... of course, if nothing else works, I need to run the simulations on one processor (but that would be slow).

How can I help?

Regards,
Philippose

[gschaider]

Originally Posted by philippose

Hello everybody,
A Good day to you all... Looks like winter has decided to step into my part of the world :-O Was greeted / threatened by a thin white veil this morning.

So, here is the current problem I am facing...:

Basic Info:
* OpenFOAM v1606+
* simpleFoam
* swak4Foam - latest mercurial commit along with patches for v1606+
* decomposed simulation
* multiple boundary conditions defined using groovyBC

Scenario:
* Need to use storedVariables in one of the boundary conditions to accumulate values.
* Everything works fine when running the simulation using one processor core (serial simulation).
* Segmentation Fault when running in parallel during the first "write to disk" iteration.

What I have figured out so far:
* Problem arises only when a patch defined using groovyBC has storedVariables.
* Problem arises only when after decomposition, the patch with the storedVariables has "0" faces in any of the processors.
* After adding "flush()" to each of the write operations in the "ExpressionResult operator<<" function, it is clear that the error occurs when trying to access the "value" entry of the storedExpressionResult object for the patch on the processor containing "0" faces.
* When using "debugCommonDriver", the simulation crashes at the start of "Time 1", when it tries to write out the result of the variable evaluation of the sortedVariable on the patch containing "0" faces.
* I have tried this also on foam-extend-3.2, and the same error occurs here too. So it is not isolated to just v1606+.
* During the decomposePar operation, the fields are written fine (groovyBC sets the fieldSize of the storedVariable to "0" and writes a "nonuniform 0()" entry for the "value"). The error occurs only during the first write operation during the solver run.

What I think:
* Looks like the "valPtr_" variable points to an invalid address for patches which have "0" faces.
* But, I am not sure yet at which point this happens, and why it happens (specially because it seems like a "fieldSize" of zero does not get any special treatment anywhere in the code).

Questions:
* Is this a known issue? (have found one reference to this on the forum, but nothing in the bug list)
* What could be a plausible solution? I tried a lot of temporary code changes, but came up with no working solution.

@Bernhard... would it be possible for you to help me out on this front? Over the last week or so, this has become a show-stopper for a couple of cases I am working on... of course, if nothing else works, I need to run the simulations on one processor (but that would be slow).

How can I help?

Regards,
Philippose

Can you provide me with a small case to reproduce the problem?

It is really possible that there is a problem with 0-length fields on some processors

[philippose]

Hello Bernhard,
Good Morning.

Thank you for the reply.

After thinking about this issue over yesterday and today, I have implemented a change into the "ExpressionResult.C" file which has currently solved the Problem.

However, I am not sure this is the best way to go. While testing this patch, I found that the issue occurs when the storedVariable is a "SingleValue",
and when the index [0] of this field is accessed during the writing process.

Obviously, for a field size of Zero, accessing the field index "[0]" would result in a Segmentation fault.

I have now included a new check to see if the field size is Zero, and if it is, create a temporary field of size 1 with empty Contents (i.e., 0 for each data type) and then write the index [0] to file.

You will find a test case, and a patch file which provides the changes I made at the following link...:

https://drive.google.com/folderview?id=0B0syP1Z1w2s1S3o3TDJUc1hjSGc

Could you please check if you are able to access the files?

Regards,
Philippose

[gschaider]

Originally Posted by philippose

You will find a test case, and a patch file which provides the changes I made at the following link...:

https://drive.google.com/folderview?id=0B0syP1Z1w2s1S3o3TDJUc1hjSGc

Could you please check if you are able to access the files?

Regards,
Philippose

Yeah. I'll have a look at the case and your fix tomorrow.

Thanks

[philippose]

Hello Bernhard,
Good Afternoon.

Thanks.

No issue. The change I made to the code works for me (I think it will also work in general cases.), so you can take your time and make the changes
you think are best for the code within a larger more generic context.

Wish you a good Weekend ahead.

Regards,
Philippose

[gschaider]

Originally Posted by philippose

Hello Bernhard,
Good Afternoon.

Thanks.

No issue. The change I made to the code works for me (I think it will also work in general cases.), so you can take your time and make the changes
you think are best for the code within a larger more generic context.

Wish you a good Weekend ahead.

Regards,
Philippose

Once I've checked the patch I'd like to commit it to the repo under your name if that is OK with you (that way I don't have to maintain the contributors list manually)

Bernhard

[philippose]

Hello Bernhard,
Thats fine... I am ok with you commiting the changes under my name.

Philippose