CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions

[swak4Foam] Segmentation Fault - groovyBC storedVariables in parallel simulations

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   November 8, 2016, 04:32
Default Segmentation Fault - groovyBC storedVariables in parallel simulations
  #1
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 21
philippose will become famous soon enough
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
philippose is offline   Reply With Quote

Old   November 8, 2016, 19:43
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,145
Rep Power: 46
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by philippose View Post
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
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   November 9, 2016, 04:28
Default
  #3
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 21
philippose will become famous soon enough
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
philippose is offline   Reply With Quote

Old   November 10, 2016, 18:08
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,145
Rep Power: 46
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by philippose View Post
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
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   November 11, 2016, 06:29
Default
  #5
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 21
philippose will become famous soon enough
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
philippose is offline   Reply With Quote

Old   November 11, 2016, 07:53
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,145
Rep Power: 46
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by philippose View Post
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
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   November 11, 2016, 09:24
Default
  #7
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 21
philippose will become famous soon enough
Hello Bernhard,
Thats fine... I am ok with you commiting the changes under my name.

Philippose
philippose is offline   Reply With Quote

Reply

Tags
groovybc, parallel simulation, segmentation fault, storedvariables, swak4foam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
ABL use of fixed shear stress leads to segmentation fault 11 cristopf OpenFOAM Running, Solving & CFD 1 December 23, 2016 16:57
Segmentation fault with parallel computing Prad Main CFD Forum 0 December 11, 2008 07:44
Segmentation Fault when using class based on KinematicParcel in parallel gschaider OpenFOAM Bugs 1 August 18, 2008 06:18
KIVA and Segmentation Fault Felix Main CFD Forum 2 January 18, 2006 01:24
Fluent parallel: segmentation fault? hp FLUENT 2 September 6, 2001 14:18


All times are GMT -4. The time now is 03:45.