View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002960 | OpenFOAM | Bug | public | 2018-05-27 10:37 | 2018-05-27 11:21 |
Reporter | fede | Assigned To | henry | ||
Priority | low | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Linux | OS | Debian | OS Version | Stretch |
Product Version | dev | ||||
Fixed in Version | dev | ||||
Summary | 0002960: cellSets in blockMesh | ||||
Description | blockMesh always removes cellSets generated from cellZones after writing polyMesh. This is not a real bug, but most probably an inconsistency: in the output log, if a cellZone is present, the info "Writing cell zones as cellSets" always appears. In blockMesh.C: - at line 371-373 cellSets are created from the corresponding cellZones: // Write as cellSet for ease of processing cellSet cset(mesh, iter.key(), zoneCells[zoneI].shrink()); cset.write(); - at line 412 mesh.removeFiles(); calls the functions removeFiles at line 1236 and then at line 1212 in polyMesh.C, to clean up files from polyMesh folder. At the end, it turns out that only cellZones are written and sets are always cancelled out, despite the output log files states that sets are written. The issue can be easily solved: - if the developers' choice is to always cancel out the cellSets from the mesh, I suggest to comment lines where cellsets are stored in the mesh definition to be written (lines 371-373), together with line 357 (info log) - if the capability to write cellSets wants to be preserved into the blockMesh (personally I would better like this option), I see two options to fix the issue: 1) add a "writeSets" option to blockMesh.C (a working piece of code is attached to this bug report) 2) include an optional argument in the function removeFiles in polyMesh, e.g: //- Remove all files from mesh instance void removeFiles(const fileName& instanceDir, const bool removeSets=false) const; //- Remove all files from mesh instance() void removeFiles(const bool removeSets=false) const; in order to be able to trigger from the public access function the (optional) removal of sets. Option 2 seems to be more elegant to me, but both works. Wish this helps! | ||||
Steps To Reproduce | 1) copy the attached blockMeshDict (it contains a very minor modification to create a cellSet) in $incompressible/icoFoam/cavity/cavity/system/ 2) run blockMesh 3) cellSets will never be created, while cellZones will be present in the mesh. 4) If you compile blockMesh.C attached in this report and you use blockMesh -writeSets cellSets are not cancelled from the mesh. | ||||
Additional Information | I follow daily updates of OpenFOAM-dev. Tests were done by version commit 507f3a576825cdcfa8e43f9de7dd939111507ea7 (May 25th, 2018) but I see that this happens with any release of OF. | ||||
Tags | No tags attached. | ||||
|
|
|
Given that the cellZones can be written why are the cellSets needed? I think the simplest solution would be to remove these lines: // Write as cellSet for ease of processing cellSet cset(mesh, iter.key(), zoneCells[zoneI].shrink()); cset.write(); |
|
Hi Henry, thank you very much for the quick answer! Once faceZones are defined in the mesh, no new additional zones can be added in a second (pre-processing) step. In my knowledge, function "addZones" can be called only once in the ode. In a workflow, I might want to add sets during the generation of the mesh, then I would like to use topoSet to create additional sets. Finally, I want to create the corresponding zones from all the sets generated in different times. For this reason, probably it would be very nice to have the option to keep track of the cellSets generated by blockMesh... |
|
Adding a specific cellSet option to removeFiles is too clunky and specific to maintain; for consistency options for each file type would need to be added. It is not clear to me why there is an issue with the adding faceZones, I think we would need to discuss this as a feature request if additional functionality is needed, but I a pretty sure this can be done with existing functionality even if it means converting zones to sets and back. |
|
Resolved by commit 03727e711db77be444ddf619c6534be8eb71d98e |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-05-27 10:37 | fede | New Issue | |
2018-05-27 10:37 | fede | File Added: blk.tgz | |
2018-05-27 10:51 | henry | Note Added: 0009655 | |
2018-05-27 11:05 | fede | Note Added: 0009656 | |
2018-05-27 11:20 | henry | Note Added: 0009657 | |
2018-05-27 11:21 | henry | Assigned To | => henry |
2018-05-27 11:21 | henry | Status | new => resolved |
2018-05-27 11:21 | henry | Resolution | open => fixed |
2018-05-27 11:21 | henry | Fixed in Version | => dev |
2018-05-27 11:21 | henry | Note Added: 0009658 |