View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000895 | OpenFOAM | Bug | public | 2013-06-20 18:39 | 2015-05-01 16:41 |
Reporter | amwouden | Assigned To | henry | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Platform | Mac | OS Version | 10.6.8 | ||
Summary | 0000895: faulty pressure relaxation in pimpleFoam solver | ||||
Description | pimpleFoam/pEqn.H contains p.relax() at line 42. But is not preceded with p.storePrevIter() causing the following error to occur: FOAM FATAL ERROR: previous iteration field IOobject: volScalarField p "personalCaseDirectory/0" not stored. Use field.storePrevIter() at start of iteration. | ||||
Steps To Reproduce | modify tutorial/pimpleFoam/TJunction/system/solution to include a relaxation factor on p. and rerun using pimpleFoam | ||||
Tags | No tags attached. | ||||
|
Consequently the same issue is present in pimpleDyMFoam and SRFPimpleFoam |
|
I was able to reproduce this error with 2.3.x as well, but only if I did this: relaxationFactors { fields { "p.*" 0.3; } equations { "U.*" 1; "k.*" 1; "epsilon.*" 1; } } This error does not occur if I do this: relaxationFactors { fields { p 0.3; } equations { "U.*" 1; "k.*" 1; "epsilon.*" 1; } } which is based on the tutorial file "incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_pimpleDyMFoam/system/fvSolution": relaxationFactors { fields { p 0.3; } equations { "(U|k|omega)" 0.7; "(U|k|omega)Final" 1.0; } } I guess is that this can be considered to be user error? |
|
The issue is that the names of the fields requiring storePrevIter must be known at the beginning of the time-step and this is infered from the list of fields requiring relaxation. To support regular expressions in this inference would require a scan of all the fields currently registered in the objectRegistry and compare the names with the regular expressions. It is likely that there will be several matches for which storePrevIter is not required which would unnecessarily increase storage. So for the moment the names of the fields requiring relaxation must be provided explicitly rather than via regular expressions. I could explicitly remove the support for regular expressions from the fields lookup but then no warning or error would be generated if a regular expressions were specified for a field; it would simply be ignored and no relaxation applied. To avoid this the fields list could be scanned for the presence of regular expressions and an error issued stating that this is not supported for fields and the names MUST be specified explicitly. I will consider this option further. |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-06-20 18:39 | amwouden | New Issue | |
2013-06-20 18:43 | amwouden | Note Added: 0002288 | |
2015-02-15 15:43 | wyldckat | Note Added: 0003782 | |
2015-02-15 17:09 | henry | Note Added: 0003785 | |
2015-02-15 17:09 | henry | Status | new => resolved |
2015-02-15 17:09 | henry | Resolution | open => no change required |
2015-02-15 17:09 | henry | Assigned To | => henry |