Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-03-05T22:00:01Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2011Can't compile with eigenVectors()2021-03-05T22:00:01ZGuanyang XueCan't compile with eigenVectors()### Summary
Can't compile the code that calculates eigenVectors() of a volSymmTensorField directly.
### Steps to reproduce
Same as the example case. eigenValues() is OK but eigenVectors() fails.
### Example case
To avoid confusion I'...### Summary
Can't compile the code that calculates eigenVectors() of a volSymmTensorField directly.
### Steps to reproduce
Same as the example case. eigenValues() is OK but eigenVectors() fails.
### Example case
To avoid confusion I'm changing the example case a little bit.
```
//Psi_ is a volSymmTensorField
eig_=eigenValues(Psi_);
R_=eigenVectors(Psi_,eig_);
```
### What is the current *bug* behaviour?
Can't compile the code.
### What is the expected *correct* behavior?
In `src/OpenFOAM/primitives/SymmTensor/symmTensor/symmTensor.H` there's
`vector eigenValues(const symmTensor& T);` and
`tensor eigenVectors(const symmTensor& T, const vector& eVals);`
eigenValues() can compile which means the conversion from `Foam::volSymmTensorField` to `const Foam::symmTensor` is OK. So eigenVectors() should work as well.
### Relevant logs and/or images
```
error: no matching function for call to 'eigenVectors'
R_=eigenVectors(Psi_,eig_);
^~~~~~~~~~~~
/Users/gux215/OpenFOAM/OpenFOAM-v2012/src/OpenFOAM/lnInclude/tensor.H:94:17: note:
candidate function not viable: no known conversion from
'Foam::volSymmTensorField' (aka 'GeometricField<SymmTensor<double>,
fvPatchField, Foam::volMesh>') to 'const Foam::tensor' (aka
'const Tensor<double>') for 1st argument
Tensor<complex> eigenVectors
^
/Users/gux215/OpenFOAM/OpenFOAM-v2012/src/OpenFOAM/lnInclude/symmTensor.H:95:8: note:
candidate function not viable: no known conversion from
'Foam::volSymmTensorField' (aka 'GeometricField<SymmTensor<double>,
fvPatchField, Foam::volMesh>') to 'const Foam::symmTensor' (aka 'const
SymmTensor<double>') for 1st argument
tensor eigenVectors
```
Also tested with GCC 8 in a Linux VM
```
/usr/lib/openfoam/openfoam2012/src/OpenFOAM/lnInclude/symmTensor.H:95:8: note: candidate: ‘Foam::tensor Foam::eigenVectors(const symmTensor&, const vector&)’
tensor eigenVectors
^~~~~~~~~~~~
/usr/lib/openfoam/openfoam2012/src/OpenFOAM/lnInclude/symmTensor.H:95:8: note: no known conversion for argument 1 from ‘Foam::volSymmTensorField’ {aka ‘Foam::GeometricField<Foam::SymmTensor<double>, Foam::fvPatchField, Foam::volMesh>’} to ‘const symmTensor&’ {aka ‘const Foam::SymmTensor<double>&’}
```
### Environment information
- OpenFOAM version : v2012
- Operating system : macOS/Linux
- Hardware info : x86
- Compiler : Clang/GCC
### Possible fixes
```
forAll(Psi_, celli) {
eig_[celli]=eigenValues(Psi_[celli]);
R_[celli]=eigenVectors(Psi_[celli],eig_[celli]);
}
```
Can be compiled successfully, but that's too stupid. It should be doable without using `forAll`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2010foamToVTK, foamToEnsight ignore pointValueField patches2021-07-29T13:58:15ZMark OLESENfoamToVTK, foamToEnsight ignore pointValueField patchesThey use internal field only.
@Prashant
Cross-ref : EP#1320They use internal field only.
@Prashant
Cross-ref : EP#1320Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2009Manually updating cellDisplacement in displacementMotionSolver2021-03-29T07:54:20ZFabien FarellaManually updating cellDisplacement in displacementMotionSolverHi!
I am pushing the displacementSBRStressFvMotionSolver to its limits when trying to run the equivalent of the SnakeRiver canyon, but with much higher resolution and complex topography.
I have modified moveDynamicMesh in order to chec...Hi!
I am pushing the displacementSBRStressFvMotionSolver to its limits when trying to run the equivalent of the SnakeRiver canyon, but with much higher resolution and complex topography.
I have modified moveDynamicMesh in order to check if the mesh contains incorrectly oriented face pyramids. It happens quiet often.
If it is the case, I load the mesh (at the end of a pimple loop) using the class Foam::Module::polyMeshGen and untangle it using Foam::Module::meshOptimizer.
I have modified the source of CFmesh in order to do that.
The problem is to re-assign the points back into the motionSolver. I understand I need to reset both the cellDisplacement and the pointDisplacement.
I tried this, but it doesnt work:
```cpp
displacementSBRStressFvMotionSolver &motionSolver = const_cast<displacementSBRStressFvMotionSolver &>(mesh.lookupObject<displacementSBRStressFvMotionSolver>("dynamicMeshDict"));
const volVectorField oldDisplacement(motionSolver.cellDisplacement());
const pointField oldC(mesh.C());
// Here I optimize the points, where Foam::Module::polyMeshGen &pmg
const pointField newPoints(optimizePoints(mesh, pmg, meshDict, report));
mesh.movePoints(newPoints);
forAll(cellDisplacement, celli)
{
cellDisplacement.primitiveFieldRef()[celli] = oldDisplacement[celli] + (mesh.C()[celli] - oldC[celli]);
}
forAll(pointDisplacement, pointi)
{
pointDisplacement.primitiveFieldRef()[pointi] = newPoints[pointi] - points0[pointi];
}
cellDisplacement.correctBoundaryConditions();
```
The change doesnt need to propagate, as I get again errors the iteration after.
But if i stop the simulation, improve the mesh using improveMeshQuality, and restart the solver, it works fine.
Any idea how to solve this?
Many thanks!!!https://develop.openfoam.com/Development/openfoam/-/issues/2008Interfacial Composition Model formulation2021-07-09T16:06:52ZHamidreza NorouziInterfacial Composition Model formulation<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam...<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam. The phase equilibrium for saturated and NRTL models are defined based on the mole-fraction while the solver uses mass fraction basis for its calculations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 or 215, the code uses the following equation to calculate specie mass fraction in the vapor phase (Yf) :
return
this->otherThermo_.composition().Y(speciesName)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
the correct equilibrium based on activity model is based on the mole fraction in pahses:
gamma_i * x_i Ps = y_i * P (Eq. 1)
where both y_i and x_i are mole fraction of component i in liquid and vapor phase.
In the code, the mole fraction of the vapor phase is converted to the mass fraction (the return value of Yf method) when we use speciesModel1_->Yf(speciesName, Tf), since in that method the return value is multiplied by Wi/W. However, the conversion of liquid phase mass fraction (otherThermo_.composition().Y(speciesName)) to mole fraction dose not occur. the correct form of the return value is
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W
/ otherThermo_.composition().Wi(species1Index_)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2006 | V2012 etc
Operating system : ubuntu
Hardware info : AMD threadripper
Compiler : gcc
### Possible fixes
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species1Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W /Wi
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
Line 215 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species2Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.W() / Wi
*speciesModel2_->Yf(speciesName, Tf)
*gamma2_;Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2007checkMesh: output fvc::laplacian of mesh.C()2021-02-18T14:40:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh: output fvc::laplacian of mesh.C()### Functionality to add/problem to solve
To additional mesh quality check for solving fc equations (e.g. fvc::laplacian, fvc::grad)
### Proposal
Write output of fvc::laplacian, fvc::grad of analytical functions in checkMesh -writeAll...### Functionality to add/problem to solve
To additional mesh quality check for solving fc equations (e.g. fvc::laplacian, fvc::grad)
### Proposal
Write output of fvc::laplacian, fvc::grad of analytical functions in checkMesh -writeAllFields. Can currently be done through coded functionObjects (e.g.
https://develop.openfoam.com/internal/OpenFOAM-nonRelease/-/blob/master/doc/Notes/dynamicCode.org)https://develop.openfoam.com/Development/openfoam/-/issues/2006Possible memory leak in setFields with surfaceToCell2021-04-08T13:48:31ZNikola MajksnerPossible memory leak in setFields with surfaceToCell
### Summary
When running setField with surfaceToCell I believe there is a memory leak. With the provided case the .obj file size is around 226 MB and setFields uses 31 GB of RAM at it's peak. Furthermore, I have tried with the file tha...
### Summary
When running setField with surfaceToCell I believe there is a memory leak. With the provided case the .obj file size is around 226 MB and setFields uses 31 GB of RAM at it's peak. Furthermore, I have tried with the file that is 770 MB and with that one RAM usage is around 215 GB at it's peak. I couldn't use the larger file as it was crashing due to not enough RAM memory.
### Steps to reproduce
Run attached case and observe memory usage when setFields command is executed
### Example case
As the case is 46 MB because of the bit larger .obj file I cannot attach it here so here is the link.
https://drive.google.com/file/d/1B4XMstiTWINkHkeTwDrl4PeJNg_wH-FC/view?usp=sharing
### What is the current *bug* behaviour?
It uses too much RAM memory.
### What is the expected *correct* behaviour?
To use way less RAM memory
### Environment information
- OpenFOAM version : v2012
- Operating system : ubuntu/docker
- Hardware info : AMD EPYC 7401P 24-Core Processor with 256 GB of RAM
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/2005objectiveManager::write hides overloaded virtual function2024-01-11T18:45:46ZMark OLESENobjectiveManager::write hides overloaded virtual functionclang complains about the `write()` method in objectiveManager, which masks the regIOobject write method.
possible corrections:
- a new name such as writeObjectives or something
- mark with 'using regIOobject::write' ?
@vaggelispclang complains about the `write()` method in objectiveManager, which masks the regIOobject write method.
possible corrections:
- a new name such as writeObjectives or something
- mark with 'using regIOobject::write' ?
@vaggelisphttps://develop.openfoam.com/Development/openfoam/-/issues/2004Potential bug with explicitPorositySource when using a cylindrical reference ...2021-02-17T14:24:39ZRiccardo RossiPotential bug with explicitPorositySource when using a cylindrical reference systemI have recently updated a model developed with the v1606 to the latest v2012 release and found an issue.
The model features a region consisting of four several cell zones where the explicitPorositySource is used to apply a pressure drop...I have recently updated a model developed with the v1606 to the latest v2012 release and found an issue.
The model features a region consisting of four several cell zones where the explicitPorositySource is used to apply a pressure drop as well as allow the flow to move perpendicularly through the zones only.
Since some of the zones are curved, a local cylindrical reference system is used to apply a finite porosity coefficient in the radial direction only.
In the v1606 (first picture attached) everything works fine but the same settings in the v2012 lead to correct behavior in the straight regions but not in the curved ones.
I've been looking in the documentation and it looks like the syntax for the reference system did not change, so I'm wondering if this could be an actual bug.
Syntax:
````
coilPackageSouthWestPorosity
{
type explicitPorositySource;
active yes;
explicitPorositySourceCoeffs
{
selectionMode cellZone;
cellZone coilPackageSouthWest;
type DarcyForchheimer;
DarcyForchheimerCoeffs
{
f (0 -1000 -1000);
d (2.209e+07 -1000 -1000);
coordinateSystem
{
type cartesian;
origin (-0.375 -0.05 0);
coordinateRotation
{
type cylindrical;
e3 (0 0 1);
}
}
}
}
}
````
![v1606](/uploads/d9add3d8559606f35ec9202b326451d3/v1606.png)
![v1912](/uploads/6dbf1184d0c1d889a26c3571223e2e84/v1912.png)https://develop.openfoam.com/Development/openfoam/-/issues/2003output face areas (normals) for raw format2021-11-25T16:16:45ZMark OLESENoutput face areas (normals) for raw formatthe raw surface writer simply outputs x/y/z values and we lose geometric information such as the area of the face and its normal. Support an output flag for adding these.
cross-ref EP 1446the raw surface writer simply outputs x/y/z values and we lose geometric information such as the area of the face and its normal. Support an output flag for adding these.
cross-ref EP 1446Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2002foamToEnsight cellZone conversion issues2021-02-16T07:45:04ZMark OLESENfoamToEnsight cellZone conversion issuesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2001Docker container feedback2021-11-25T16:17:36ZFabian FribergDocker container feedback### Functionality to add/problem to solve
I made a thread on CFD online talking about the difference between docker containers for OF7 and OFv2006, asking if there's a way to run OFv2006 with the OF7 container. A person replied saying I...### Functionality to add/problem to solve
I made a thread on CFD online talking about the difference between docker containers for OF7 and OFv2006, asking if there's a way to run OFv2006 with the OF7 container. A person replied saying I should post my feedback regarding the containers here. [Here's a link to the thread](https://www.cfd-online.com/Forums/openfoam-installation/233285-docker-problems.html).
Here are the concerns I brought up in the thread:
> I first installed OF7 on my mac using docker, and it worked great. The script creates a contained environment where only the directory I launched the script from exists, and all alias shortcuts (like src, run etc) work.
>
>
> Then I installed OFv2006, and the docker script is different. It creates an image of my entire file system which always starts at my home directory so I have to navigate to the right folder, and the user directory shortcut aliases/variables don't work (like run or cd $FOAM_USER_APPBIN).
>
>
> For example, echo $FOAM_RUN gives //OpenFOAM/lumpor-v2006/run, which doesn't exist The two '/' characters at the start confuse me. I tried changing "home" to "pwd" in some places in the v2006 docker file, but it doesn't seem to work.
> Also, using the OF7 container I can make changes in my working directory from outside the terminal in real-time, while for the OFv2006 container I need to restart the container every time I edit any files.
### Target audience
Mac users of OFv2006/2012
### Proposal
By making changes to the docker file for v2012.
### What does success look like, and how can we measure that?
Mac users being able to use docker more easily for openfoam. An increase in use of OF for mac and/or a survey would be ways to measure it.
### Links / references
N/A
### Funding
N/Ahttps://develop.openfoam.com/Development/openfoam/-/issues/2000Support surface sampling on internal fields2021-02-09T19:26:52ZMark OLESENSupport surface sampling on internal fieldsMentioned on cfd-online, could be useful to sample internal (dimensioned) fields. Will work for many surface types, but might need special care for patch samplers etc.Mentioned on cfd-online, could be useful to sample internal (dimensioned) fields. Will work for many surface types, but might need special care for patch samplers etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1999surfaceFieldValue surface writer (VTK) fails with multiple fields2021-02-17T12:46:07ZMark OLESENsurfaceFieldValue surface writer (VTK) fails with multiple fieldscross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.cross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1998change default setting for sigFpe2021-02-10T12:33:30ZMark OLESENchange default setting for sigFpeReported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loo...Reported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loops?
@andy @Mattijs @Sergio @kuti @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/1997Outer boundaries deformed during layer addition in snappyHexMesh2021-07-07T10:58:55ZChiara PesciOuter boundaries deformed during layer addition in snappyHexMesh<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The outer boundaries of a mesh are deformed when adding layers with snappyHexMesh. The issue occurs only when all the outer boundaries/patches belong to a single patch. If the outer block is composed by separated patches, i.e. inlet, outlet, front, etc., then the outer boundary is not deformed during the layer addition step.
### Steps to reproduce
Run the tutorial [airfoilWithLayers](https://develop.openfoam.com/Development/openfoam/-/tree/master/tutorials/mesh/snappyHexMesh/airfoilWithLayers) and check the outer patches.
### Example case
Attached you can find a modified version of the tutorial mentioned above to reproduced the two cases, one with single outer patch and one with separated patches from blockMesh.
[airfoilWithLayers_outerBoundary.tgz](/uploads/2b273eb3a3fb231bb4026b93c80210d3/airfoilWithLayers_outerBoundary.tgz)
### What is the current *bug* behaviour?
During the layer addition phase in snappyHexMesh the outer boundary is deformed together with the internal mesh; see attached figure.
This occurs only when the outer boundary is a single patch.
### What is the expected *correct* behavior?
The outer boundary should not be deformed; see the right picture in the figure attached.
### Relevant logs and/or images
![compare_snap](/uploads/86f6a025944b4d1e9c3e6abeef844eaf/compare_snap.png)
![compare_addLayers](/uploads/9296282ed4029b3ce858754d26aa93ca/compare_addLayers.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1994Dead code, Unused files2024-01-11T18:18:23ZVolker WeißmannDead code, Unused filesI wanted to report that the following files seem to be dead code (grep $FILENAME did not find anything).
You might want to delete them.
```
dead code: graphTest2.C
dead code: Test-ExtendedStencil2.C
dead code: basicSymmetryFaPatchFields...I wanted to report that the following files seem to be dead code (grep $FILENAME did not find anything).
You might want to delete them.
```
dead code: graphTest2.C
dead code: Test-ExtendedStencil2.C
dead code: basicSymmetryFaPatchFields.C
dead code: extendedFeatureEdgeMeshTemplates.C
dead code: PolynomialIO.C
dead code: curveTools.C
dead code: findRefCells.C
dead code: unweightedLeastSquaresVectors.C
dead code: invDistLeastSquaresVectors.C
dead code: fvcSimpleReconstruct.C
dead code: adjointZeroInletFvPatchFieldsFwd.C
dead code: adjointBoundaryConditionTemplates.C
dead code: fluent3DMeshToFoam.L.C
dead code: fluentMeshToFoam.L.C
dead code: ansysToFoam.L.C
dead code: gambitToFoam.L.C
dead code: STLAsciiParseFlex.L.C
dead code: chemkinLexer.L.C
```
grep $FILENAME also fails for the following files, but you propabley don't want to delete them
```
dead code: _TemplateTemplate.C
dead code: _TemplateTemplateIO.C
dead code: _TemplateApp.C
dead code: _TemplateIO.C
dead code: _Template.C
```https://develop.openfoam.com/Development/openfoam/-/issues/1993PR: Nonexisiting includes2021-02-22T14:18:43ZVolker WeißmannPR: Nonexisiting includesI found that in some Make/options , there are "-I/path/to/non-exisisting/dir/" options. The patch below removes those options.
This makes some of the warnings of ./generate_meson_build.py disappear.
Please merge them into master.
Test...I found that in some Make/options , there are "-I/path/to/non-exisisting/dir/" options. The patch below removes those options.
This makes some of the warnings of ./generate_meson_build.py disappear.
Please merge them into master.
Tested on 441fd9b1a64f7c794f92b6aaba81238c08d4b64d .
[removed_includes.patch](/uploads/9540b38108e44a734cc7faf188c10248/removed_includes.patch)https://develop.openfoam.com/Development/openfoam/-/issues/1992Error tracking a particle when the containing cell is unrefined (DPMDyMFoam)2023-10-10T14:42:11ZJairo Andrés GutiérrezError tracking a particle when the containing cell is unrefined (DPMDyMFoam)
### Summary
<!-- Summarize the bug encountered concisely -->
OpenFOAM crashes when the mesh is unrefined using DPMDyMFoam. It happens when any level+1 cell containing a particle is unrefined 1 level. The error message is:
FOAM FATAL...
### Summary
<!-- Summarize the bug encountered concisely -->
OpenFOAM crashes when the mesh is unrefined using DPMDyMFoam. It happens when any level+1 cell containing a particle is unrefined 1 level. The error message is:
FOAM FATAL ERROR: (openfoam-2012) Cell not found for particle position (-0.0056421567 -0.081679551 -0.0117107).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Steps:
1 - blockMesh (the grid is simple but parametrized, so it will take 1 min).
2 - DPMDyMFoam.
3 - Stop after time 0.005 is reached (1 - 2 mins) and the solution is saved.
4 - Use a higher unrefinement value (dynamicMeshDict --> lowrefinementlevel 2; unrefinementlevel 1;
5 - Run DPMDyMFoam again and the error presets itself after unrefinement.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
[bugDPMDyMFoam.zip](/uploads/fcab30b3f37262d802b61bddbddd6195/bugDPMDyMFoam.zip)
[generalScheme.pdf](/uploads/fbb2cce5251a2231ea804c1f220229c7/generalScheme.pdf)
I have provided a case. The particles are injected in the primary jet (see pdf), which also contains air.
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
- OpenFOAM version : v2012 (Also present in V1912 and V1706
- Operating system : ubuntu
- Hardware info :
- Compiler : precompiled
### Possible fixes
To fix:
in "void Foam::particle::locate" --> change "const label celli," for "label celli,"
and modify the rest of the code to:
// Find the cell, if it has not been given
if (celli < 0)
{
celli = mesh_.cellTree().findInside(position);
}
if (celli < 0) // replaced celli_ with celli
{
FatalErrorInFunction
<< "Cell not found for particle position " << position << "."
<< exit(FatalError);
}
celli_ = celli; // moved this definition to the bottom
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1990Possible bug in snappyHexMesh for large coordinates2021-07-07T10:56:02ZEden Furtak-ColePossible bug in snappyHexMesh for large coordinates<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
For large coordinates, snappyHexMesh stops refinement after two levels.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
snappyHexMesh stops refinement in directions corresponding to large coordinates. This is a problem when working in geographic coordinates. In the attached casefile, will see that refinement is performed in the x and z directions, but stops after two levels in the y direction. I suspect that this is because the y coordinate is on the order of e+6, while the x direction is e+5, and z is close to zero. I don't know if this is a known issue, I have not found any information about it.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
[bad_mesh.tar.xz](/uploads/4e0c7967a2e068d2eda6e613b7333828/bad_mesh.tar.xz)
I attached a very small casefile. Run blockMesh and snappyHexMesh.
### What is the current *bug* behaviour?
<!-- What actually happens -->
No refinement in the y direction after two levels.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Refinement in all directions, regardless of coordinates.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
![image](/uploads/d23fadba8294f683095cbb11fa945c58/image.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : 2006
- Operating system : CentOS 7
- Hardware info : Dell Precision 3630
- Compiler : gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
If the case is translated to the origin the problem goes away. This makes me think this is a bug, but I can't point to the part of the code that is causing this. snappyHexMesh finishes without errors.https://develop.openfoam.com/Development/openfoam/-/issues/1989Feature: Mesh motion and adaptive mesh refinement2021-07-07T10:55:37ZAkash PatelFeature: Mesh motion and adaptive mesh refinement### Functionality to add/problem to solve
Enabling mesh motion to work along with adaptive mesh refinement
### Target audience
Beneficial in fluid structural interaction cases and moving mesh simulations.
### What does success look l...### Functionality to add/problem to solve
Enabling mesh motion to work along with adaptive mesh refinement
### Target audience
Beneficial in fluid structural interaction cases and moving mesh simulations.
### What does success look like, and how can we measure that?
I have done some work towards this with no apparent success. Motion engine doesn't recognize newly refined mesh points.
I looked at [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C#L432) commented code and it tells me that someone in past has tried to work on this feature but it hasn't been enabled yet.
How challenging this has been (if the OpenFOAM team has already tried this) or would be to implement? Anyone can provide me with the level of effort it would require? I have not seen any solid efforts towards this in the community.
Thank you!