View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001495 | OpenFOAM | Bug | public | 2015-01-21 09:27 | 2017-04-25 14:02 |
| Reporter | tniemi | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0001495: mapFields breaks boundary conditions with extra field entries | ||||
| Description | In 2.3.x it seems that if a boundary condition has extra fields, such as inletValue-field in inletOutlet, it will get mapped to uninitialized random values. I have traced the issue through the code and I think that the problem lies in the directFvPatchFieldMapper used in the target boundary construction. The directFvPatchFieldMapper gets created on line 574 in meshToMeshTemplates.C with a value of -1 for each item. When this mapper is then used to create the target boundary, the extra fields will have uninitialized values, because the mapper can't do anything reasonable. The value field of the boundary condition will get interpolated later on with proper values, but the other fields are left to the uninitialized random state. This issue was not present in 2.1.x, where the mapping code is different. I think in 2.1.x the mapper has reasonable values which are used to map the other fields. I have attached a simple test case pair (source target) based on the cavity-tutorial, which should demonstrate the issue. Both cases are identical and the only change compared to the cavity tutorial is that the boundary conditions for walls in p are changed to inletOutlet with uniform and non uniform inletValues. Running mapFields -consistent from source to target will create a target boundary conditions with random inletValues. In my test case the resulting inletValues have entries such as 1.1439e-312 1.1439e-312 0 1.65942e-316 ... In actual test cases inf and -nan values are ofter produced, which will immediately crash the solver. Note: If the source target has a unknown boundary type (ie. generic), the extra field will transfer correctly, if they are uniform. Non-uniform fields will be corrupted, as they are mapped with the -1 mapper. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-01-21 09:27 | tniemi | New Issue | |
| 2015-01-21 09:27 | tniemi | File Added: example_case.zip | |
| 2015-02-05 12:20 | henry | Note Added: 0003692 | |
| 2015-02-05 12:20 | henry | Status | new => resolved |
| 2015-02-05 12:20 | henry | Resolution | open => fixed |
| 2015-02-05 12:20 | henry | Assigned To | => henry |
