Community issueshttps://develop.openfoam.com/groups/Community/-/issues2021-08-09T14:19:48Zhttps://develop.openfoam.com/Community/integration-cfmesh/-/issues/7Meshing the smallest domain in a multi-domain geometry2021-08-09T14:19:48ZBas NieuwboerMeshing the smallest domain in a multi-domain geometry### Functionality to add/problem to solve
Currently it is not possible to mesh the smallest domain in a multi-domain geometry. Cfmesh allways meshes the domain with the largest number of cells. In some cases this is unwanted such as a me...### Functionality to add/problem to solve
Currently it is not possible to mesh the smallest domain in a multi-domain geometry. Cfmesh allways meshes the domain with the largest number of cells. In some cases this is unwanted such as a mesh for the flow between two concentric cylinders. In snappyHexMesh this is solved using the locationInMesh keyword. This is not available in Cfmesh.
### Proposal
Franjo Juretic did implement a basic feature for multi-domain meshing as explained on [cfdonline].
It was pushed to github in a new branch. The commit which enables this is: https://github.com/philippose/cfMesh/commit/7230c449e9a5461a1f0e4aae91bd0117bcd98f26
I’ve implemented this commit in the module of cfMesh for openfoam v2106 and attached the two files that I’ve changed. This allows the use of the keyword: 'allowDisconnectedDomains 1' which is explained in the [cfd online] tread. Problem with this method is that the internal domains are not mapped to the geometry. At least the cellset was not mapped and the resulting mesh using subsetmesh was not snapped to the surface.
As a solution I implemented the keepDomainNumber keyword, which allows you to chose which domain you want to keep. This is not a preferred solution, but it allows you to first visualize all the domains using the allowDisconnectedDomains keyword and in a second attempt mesh the domain number you want to keep.
The best solution would be to implement the locationInMesh keyword. However that is beyond my level to implement.
Using these 2 methods one can view the whole mesh and view the different domains. Then select a single domain using the keepDomainNumber keyword.
### What does success look like, and how can we measure that?
I’ve tested it using an own geometry. One can test it using two concentric cylinders with and without the allowDisconnectedDomains keyword. When enabling the function it should make 2 cell-zones. With the keepDomainNumber keyword you should be able to chose between the two domains.
### Links / references
[cfd online] https://www.cfd-online.com/Forums/openfoam-community-contributions/150500-how-does-cfmesh-determine-region-mesh.html
[checkCellConnectionsOverFaces.C](/uploads/d0d265dbe1ae7ee312685c1afa453ab7/checkCellConnectionsOverFaces.C)
[meshOctreeAddressingCreation.C](/uploads/944475fd0c3ac7102ecd296c65c3229a/meshOctreeAddressingCreation.C)https://develop.openfoam.com/Community/avalanche/-/issues/6Incorrect gravitational vector in the friction models2023-07-05T05:10:18ZBas NieuwboerIncorrect gravitational vector in the friction modelsIn the friction models, for instance the manninStrikcler, the vertical component of the gravitational vector is used. This is incorrect, since it is the component normal to the bed which will induce the friction. A thought experiment is ...In the friction models, for instance the manninStrikcler, the vertical component of the gravitational vector is used. This is incorrect, since it is the component normal to the bed which will induce the friction. A thought experiment is to think about a very steep (nearly vertical) slope. For this slope, the friction should be near zero. The normal component of the gravitation vector would be nearly zero and is the right component to use.
In my application I only needed the manningStrickler friction and adapted these files together with the frictionModel to include the normal component of the gravity. I've included the changes I made to these files. Obviously, also the call to the friction constructor should be updated in the solver.
I've also read in the dimensionless manning coefficient and changed the units in the class so the input file becomes less cluttered. I can imagine that incorporating this is somewhat more difficult.
[frictionModel.H](/uploads/bfd22a04eb3a3feb6294e7c5f9eca36d/frictionModel.H)
[frictionModelNew.C](/uploads/224cd548cf5a4445e359b18dbfef9141/frictionModelNew.C)
[frictionModel.C](/uploads/c5e7987046c35159e95f68cf0aed4da0/frictionModel.C)
[ManningStrickler.C](/uploads/e677c95a8d8c0035401b802585c2cc63/ManningStrickler.C)
[ManningStrickler.H](/uploads/71974f7543978f892918cc8f0ce91c96/ManningStrickler.H)Matti RauterMatti Rauterhttps://develop.openfoam.com/Community/hydrology/-/issues/4Diffusion of the results of our work on the permaFoam solver itself2022-06-05T07:59:52ZLaurent OrgogozoDiffusion of the results of our work on the permaFoam solver itselfHi Mark,
Beside the on-going work on the advanced BCs to be used on the supercomputers IRENE, Occigen and Olympe, I think it is time to think about the diffusion of the results of our work on the solver permaFoam itself. In addition, I ...Hi Mark,
Beside the on-going work on the advanced BCs to be used on the supercomputers IRENE, Occigen and Olympe, I think it is time to think about the diffusion of the results of our work on the solver permaFoam itself. In addition, I did also a new version of RichardsFoam (the OpenFOAM solver for soil hydrology without freeze/thaw, on which was build teh first version of permaFoam) based on the improvements we worked on for permaFoam whenever it was possible. More precisely I did this new version by degenerating the updated permaFoam version, deleting all the stuff related to heat transfers, and thus transmitting our improvements directly in this 'permaFoam mediated' new version of RichardsFoam, that I called RichardsFoam3.
Please find here the two new packages to be released, for rereading, suggestions and corrections :
- permaFoam : here is the new package with the updated solvers, BCs, demonstration case and presentation documents[permaFoam_2BeReleased.zip](/uploads/ec37435324c716e7ba60c497c71b7082/permaFoam_2BeReleased.zip).
- RichardsFoam3 : here is the new package with the updated solvers, BCs, demonstration case and presentation documents[RichardsFoam3_2BeReleased.zip](/uploads/61cfcc9cbf45697d7f5f3d0cb96a85a4/RichardsFoam3_2BeReleased.zip).
Please note two important points:
- Contributor list in the codes: I include your name in the contributor list at the beginning of each .C file for the two solvers. I feel that this is logical since you are now the person that did the most important contributions to the coding itself after me. Nevertheless of course if you don't want to appear namely as a contributor to permaFoam and RichardsFoam3, please let me know.
- Co-authorship of the new version announcements to be submitted to Computer Physics Communications¤: as you can see in the two packages above, I intend to submit new version announcements to CPC in order to advertise theses new version. In that way there will be quickly quotable contents to refer to when dealing with permaFoam and RichardsFoam3, and the released will be stored in the CPC code library. Moreover it would be in-line with the previous diffusion practice for RichardsFoam (published in CPC - Orgogozo et al., 2014 - , stored in the CPC code library) and the previous updated version RichardsFoam2 (Announced in CPC -Orgogozo 2015 - , stored in the CPC code library). You will note that in the drafts of the announcements (see the .tex and the .pdf CPCNVA_XYZ in the packages above), you appear as co-author of these new versions. I think this is logical since these new versions are the results of our collaboration. Nevertheless please let me know if you don't want to be co-author of these new version announcements.
It is a great satisfaction for me that these new versions have been produced. Thank a lot for your help!
Cheers,
Laurent
¤ [https://www.journals.elsevier.com/computer-physics-communications/](url)https://develop.openfoam.com/Community/adiosfoam/-/issues/3adios support for mapFields2020-09-24T09:37:18ZJohan Hiddingadios support for mapFieldsHi, is it possible to use `mapFields` with adios data?
regards, Johan HiddingHi, is it possible to use `mapFields` with adios data?
regards, Johan Hiddinghttps://develop.openfoam.com/Community/hydrology/-/issues/3stabilizing solver, boundary conditions2021-02-17T09:13:31ZMark OLESENstabilizing solver, boundary conditionsReworked solver (slightly) and implemented boundary conditions.
Initial solution has similar behaviour as the shipped log files, but then diverges.
@SergioReworked solver (slightly) and implemented boundary conditions.
Initial solution has similar behaviour as the shipped log files, but then diverges.
@SergioMark OLESENMark OLESENhttps://develop.openfoam.com/Community/adiosfoam/-/issues/1Minor changes: placeholder2020-06-25T07:30:47ZPrashant SonakarMinor changes: placeholder- reconstructPar doesn't do anything in `heatTransfer/chtMultiRegionFoam/multiRegionHeater` tutorial
- the solver has following warnings during simulation
```
--> FOAM Warning :
From Foam::label Foam::functionObjects::adiosWrite::wr...- reconstructPar doesn't do anything in `heatTransfer/chtMultiRegionFoam/multiRegionHeater` tutorial
- the solver has following warnings during simulation
```
--> FOAM Warning :
From Foam::label Foam::functionObjects::adiosWrite::writeFields(const Foam::adiosFoam::regionControl&, bool)
in file adiosWriteData.C at line 165
1 fields not handled by adiosWrite
names: 1(cumulativeContErr)
types: 1(uniformDimensionedScalarField)
```
@markhttps://develop.openfoam.com/Community/integration-cfmesh/-/issues/2potential sizing issue for DynList2017-11-04T15:30:15ZMark OLESENpotential sizing issue for DynListNot sure if this is intentional or not. For the constructor
DynListCame(label sz)
will set both the allocated size and the addressable area to be `sz`. The `testDytestDynList.C`
https://develop.openfoam.com/Community/integration-...Not sure if this is intentional or not. For the constructor
DynListCame(label sz)
will set both the allocated size and the addressable area to be `sz`. The `testDytestDynList.C`
https://develop.openfoam.com/Community/integration-cfmesh/blob/port-v1712/testingInterfaces/testDynList/testDynList.C#L40
and https://develop.openfoam.com/Community/integration-cfmesh/blob/port-v1712/testingInterfaces/testDynList/testDynList.C#L50
suggests that this may not be intended (the addressable content being any random junk).
I seem to remember having something similar in a very early incarnation of DynamicList, but this form of the constructor got changed to meaning the same as "reserve allocated space, but start with a zero addressable size".
I did a quick check (by temporarily removing this constructor) and it doesn't seem to be used in too too many places. Nonetheless, it could be worth taking a look at.
@Juretic