Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-06-24T11:15:59Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2513How to submit a Pull/Merge Request?2022-06-24T11:15:59ZAkash PatelHow to submit a Pull/Merge Request?Hello all, I've added some functionality to openfoam that I believe others would find useful, however, I am not sure how to fork this repo and create pull/merge request.
In the first place, I was not able to create a fork of the repo, s...Hello all, I've added some functionality to openfoam that I believe others would find useful, however, I am not sure how to fork this repo and create pull/merge request.
In the first place, I was not able to create a fork of the repo, so I am doing the developing on a clone of this repo. Which seems to be what is recommended anyhow: https://develop.openfoam.com/Development/openfoam/-/wikis/coding/git-workflow#workflow
I tried following the directions on the wiki to [submit my code](https://develop.openfoam.com/Development/openfoam/-/wikis/coding/git-workflow#submitting-for-code-review), however, I get the following error:
```
128 acxz@archard ../openfoam/src/renumber/renumberMethods (git)-[feature-symamd] % git push -u origin feature-symamd
remote:
remote: ========================================================================
remote:
remote: You are not allowed to push code to this project.
remote:
remote: ========================================================================
remote:
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
Which makes sense, since we probably don't want anyone to willy nilly spam the git branches of this repo.
Ideally, users should be able to fork this repo and then submit merge requests, instead of creating requests from upstream branches.
In any case, how can I create a merge request to openfoam?Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2512write ensight case after fields2022-08-19T09:13:10ZMark OLESENwrite ensight case after fieldsAs noted in EP1918, if something causes the surface field writing to crash, the Ensight case file will contain entries to invalid/corrupt files. It thus makes sense to only commit the updates to the case file _after_ the writing has comp...As noted in EP1918, if something causes the surface field writing to crash, the Ensight case file will contain entries to invalid/corrupt files. It thus makes sense to only commit the updates to the case file _after_ the writing has completed.v2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2511memory leak from forces FO2022-06-23T10:32:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commemory leak from forces FO<!--
*** 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 -->
Run mixerVesselAMI2D-topologyChange under valgrind (with 'endTime writeNow') produces memory error from forces functionObject.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See above
### 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
-->
See above
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2204
- Operating system :
- 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
-->
[processor0.log](/uploads/06d4839288fc5b4b143f0d4e92b70dc8/processor0.log)
@kutiAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2510sphereDrop tutorial does not run to the end2024-01-10T11:02:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsphereDrop tutorial does not run to the end<!--
*** 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 -->
sphereDrop tutorial does not run far with layer addition.
Smaller issues:
- runs with PCG on pcorr but GAMG on p_rgh
- runs pcorr to unnecessary tight tolerance?
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Change end time on sphereDrop tutorial to 0.7 instead of 0.07.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Case diverges at some point - alpha max gets above 1.
### 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.
-->
At around time 0.1992 the deltaT goes from e-5 to e-6 due to the Courant number. After that it starts getting lower and lower (assume velocity goes up - not checked). I've tried with 4 outer correctors but that didn't help.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2509Build system refers to non-existent directories2022-06-15T09:49:20ZIlya PopovBuild system refers to non-existent directoriesIn the current `develop` branch, I noticed the following:
- [`src/TurbulenceModels/compressible/Make/options` refers to `-I$(LIB_SRC)/regionCoupled/lnInclude`](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/Turbule...In the current `develop` branch, I noticed the following:
- [`src/TurbulenceModels/compressible/Make/options` refers to `-I$(LIB_SRC)/regionCoupled/lnInclude`](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/TurbulenceModels/compressible/Make/options#L5), which does not exist
- [`src/regionModels/regionCoupling/Make/options` refers to `-I$(LIB_SRC)/turbulenceModels/lnInclude`](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/regionModels/regionCoupling/Make/options#L15), which does not existMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2508intel compiler issue:2022-06-28T11:07:31ZPawan Ghildiyalintel compiler issue:Hello All,
WIth same environment set up , I am able to compile v2112 but unable to compile
latest dev branch
`/cineca/prod/opt/compilers/intel/pe-xe-2018/binary/bin/icc`
It is throwing following messages
```
icpc -std=c++14 -...Hello All,
WIth same environment set up , I am able to compile v2112 but unable to compile
latest dev branch
`/cineca/prod/opt/compilers/intel/pe-xe-2018/binary/bin/icc`
It is throwing following messages
```
icpc -std=c++14 -pthread -fp-trap=common -fp-model precise -DOPENFOAM=2204 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-unknown-pragmas -diag-disable 327,654,1125,1292,2289,2304,11062,11074,11076 -O3 -DNoRepository -I/marconi_scratch/userexternal/pghildiy/openfoam-dev/build/linux64IccDPInt32Opt/src/OpenFOAM -DHAVE_LIBZ -iquote. -IlnInclude -I/marconi_scratch/userexternal/pghildiy/openfoam-dev/src/OpenFOAM/lnInclude -I/marconi_scratch/userexternal/pghildiy/openfoam-dev/src/OSspecific/POSIX/lnInclude -fPIC -c db/IOstreams/Pstreams/IPBstreams.C -o /marconi_scratch/userexternal/pghildiy/openfoam-dev/build/linux64IccDPInt32Opt/src/OpenFOAM/db/IOstreams/Pstreams/IPBstreams.o
Internal error loop: assertion failed: find_seq_in_lookup_table: seq_number not found (shared/cfe/edgcpfe/il.c, line 4118)
compilation aborted for db/IOstreams/Pstreams/IPBstreams.C (code 4)
make: *** [/marconi_scratch/userexternal/pghildiy/openfoam-dev/build/linux64IccDPInt32Opt/src/OpenFOAM/db/IOstreams/Pstreams/IPBstreams.o] Error 4
```https://develop.openfoam.com/Development/openfoam/-/issues/2507regression in finiteArea processor boundaries2023-02-22T08:29:37ZMark OLESENregression in finiteArea processor boundariesAs noted by @Chiara - the processor boundaries are visible in the current develop.
@Sergio tracked it down and we have added the processor update inside of the init() routine.
In previous versions the processor/processor update was bein...As noted by @Chiara - the processor boundaries are visible in the current develop.
@Sergio tracked it down and we have added the processor update inside of the init() routine.
In previous versions the processor/processor update was being invoked as a side effect of the regular geometry calculation, but needed to removed from there since there where cases (ie, redistributePar) where things are being called differently on different processors.v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2506Potential bugs in integratedNonUniformTable and nonUniformTable2022-06-27T14:37:49ZVaggelis PapoutsisPotential bugs in integratedNonUniformTable and nonUniformTable### Summary
1. `nonUniformTable::index(...)` will return a negative index if the input temperature is lower than `Trange_.min()`, which will then cause the simulation to crash when used in the `jumpTable_`
2. The piece-wise integrals o...### Summary
1. `nonUniformTable::index(...)` will return a negative index if the input temperature is lower than `Trange_.min()`, which will then cause the simulation to crash when used in the `jumpTable_`
2. The piece-wise integrals of f and fByT seem to be computed wrongly in the constructor of `integratedNonUniformTable`. Since the `intfdT` and `intfByTdT` functions already add the integral up until the previous point, these shouldn't be added again in the constructor, right?
### Environment information
- OpenFOAM version : develop branch
- Compiler : gcc-9.3.0
### Possible fixes
1. In `nonUniformTable::index`, use maybe
```
if (T >= Trange_.min() && T <= Trange_.max())
{
nd = (T - Trange_.min())/deltaT_;
}
else if (T > Trange_.max())
{
nd = (Trange_.max() - Trange_.min())/deltaT_;
}
else if (T < Trange_.min())
{
nd = 0;
}
```
instead of
```
if (T > Trange_.min() || T < Trange_.max())
{
nd = (T - Trange_.min())/deltaT_;
}
else if (T > Trange_.max())
{
nd = (Trange_.max() - Trange_.min())/deltaT_;
}
```
lines 40-47 of nonUniformTableThermophysicalFunctionI.H.
As the code stands, if `T < Trange_.min`, the first branch will give a negative `nd` value.
2.
```
for (label i = 1; i < intf_.size(); ++i)
{
// Maybe use these ...
intf_[i] = intfdT(0, values()[i].first());
intfByT_[i] = intfByTdT(0, values()[i].first());
// ... instead of these
//intf_[i] = intf_[i-1] + intfdT(0, values()[i].first());
//intfByT_[i] = intfByT_[i-1] + intfByTdT(0, values()[i].first());
}
```
lines 69-70 of integratedNonUniformTable.C.
since `intf_[i-1]` and `intfByT_[i-1]` are already added in the `intfdT` and `intfByTdT` functions.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2505add coordinate transforms to surface writer output2022-08-19T10:56:52ZMark OLESENadd coordinate transforms to surface writer outputcross-ref EP1886 @martin.werther
Discussed the need to have different locations for the output sampled surface (eg, to relocate into the original car coordinate system and scale in mm).
We already have geometry scaling, but that is mo...cross-ref EP1886 @martin.werther
Discussed the need to have different locations for the output sampled surface (eg, to relocate into the original car coordinate system and scale in mm).
We already have geometry scaling, but that is mostly ad hoc for a few select writers. With this change it would make sense to add in a general cartesian coordsys transform. For example,
```
transform
{
origin (5 1 0);
e1 (0 1 0);
e3 (0 0 1)
}
```
This syntax can also be extended with the `rotation` sub-entry. For example,
```
transform
{
origin (5 1 0);
rotation
{
type euler;
order rollPitchYaw;
angles (0 0 90)
}
}
scale 1000; // [m] -> [mm]
```
These are applied in the OpenFOAM global MKS coordinate system, and the scaling is applied afterwards.v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2504Error in particle/ACMI_blockage interaction2022-06-09T13:05:19ZHerbert TauberError in particle/ACMI_blockage interactionA memory access error occurs when a particle interacts with the ACMI_blockage.
MPPICDyMFoam is used.
A simple case and a log-file is included. There are two offset rectangular areas, connected by ACMI.
Two particles are dropped in the u...A memory access error occurs when a particle interacts with the ACMI_blockage.
MPPICDyMFoam is used.
A simple case and a log-file is included. There are two offset rectangular areas, connected by ACMI.
Two particles are dropped in the upper rectangle. One particle falls through ACMI_couple and
the other on ACMI_blockage. When the second particle touches ACMI_blockage, I get
a memory access error.
[ACMI-test.zip](/uploads/dcf01db4441f5c92f98147b901045d2e/ACMI-test.zip)
### Environment information
- OpenFOAM version : v2112
- Operating system : ubuntu 20.04
- Hardware info :
- Compiler :
Best regards
Herberthttps://develop.openfoam.com/Development/openfoam/-/issues/2503Atmosphericmodels only works properly for default C1 and C2 values2022-07-22T05:24:12ZChristian RohrAtmosphericmodels only works properly for default C1 and C2 valuesIt appears that the atm wall functions and both (r)kEpsilon and kOmegaSST are not in balance when non-default values for C1 and C2 are used.
For example, for higher levels of turbulence (e.g. C1 = 0, C2 = 10), k immediately decays near...It appears that the atm wall functions and both (r)kEpsilon and kOmegaSST are not in balance when non-default values for C1 and C2 are used.
For example, for higher levels of turbulence (e.g. C1 = 0, C2 = 10), k immediately decays near the wall. This can be reproduced in the `atmDownstreamDevelopment` tutorial case. Is this intended behaviour?
![image](/uploads/657cf2214e13e9d6ac0b4f73e29162f2/image.png)
Can the wall functions for either Epsilon or Nut be modifed to include the appropriate corrections to allow for generation of k at the rate balanced with the specified inlet turbulence?https://develop.openfoam.com/Development/openfoam/-/issues/2502BUG: nearWallDist not updated during optimisation2022-06-28T09:46:28ZVaggelis PapoutsisBUG: nearWallDist not updated during optimisation### Summary
When running adjointOptimisationFoam in steadyOptimisation mode, the `nearWallDist` in the primal turbulence model is not updated.
A bit of background:
Up until 0f00ac2d8ca, `fvMesh::Vsc()` (used e.g. in `fvc::grad()`) w...### Summary
When running adjointOptimisationFoam in steadyOptimisation mode, the `nearWallDist` in the primal turbulence model is not updated.
A bit of background:
Up until 0f00ac2d8ca, `fvMesh::Vsc()` (used e.g. in `fvc::grad()`) would return a fraction of the actual cell volume if the mesh was moving and time was sub-cycled. Both these conditions are met in shape optimisation after the first mesh update, so this would lead to a blown-up simulation if not treated. Hence, after moving the mesh in each mesh update, the mesh `moving` flag is set to false in `displacementMethod::update()`. This has the following unwanted side-effects
1. `nearWallDist` is not updated in the turbulence model, since it is safeguarded by `mesh_.changing()`. This means that the initial values are used for all geometries throughout the optimisation cycles, despite the fact that the geometry has changed. Note that `wallDist` inherits from `MeshObject` and is updated properly the moment the mesh points change, irrespective of the `moving` or `changing` flags in `fvMesh`.
2. When the mesh changes, cached fields should be cleared. This is managed in `gradScheme<Type>::grad()` by the `mesh_.changing()` flag, but since the `moving` flag is set to false after each mesh update, this fails to delete the cached fields. As a result, the first iteration of each optimisation cycle after the first one will be slightly different if we cache gradients, leading to a slightly different optimisation convergence. This is not critical, but it creates an inconsistency that shouldn't be there.
After 0f00ac2d8ca, `fvMesh::Vsc()` is also safeguarded by `fvMesh::steady()`, so `fvMesh::moving()` can be left to true without blowing up the simulation. This, however, creates problems of its own
1. Since now the mesh is seen as moving, cached fields will be cleared in _all_ iterations of the primal, after the first mesh update, loosing whatever time gain we have from there.
2. In an unsteady optimisation, it is mandatory to switch `fvMesh::moving()` to false, otherwise we will get erroneous `meshPhi` fluxes to our flow equations.
For the moment, with only steady optimisation available publicly, leaving `fvMesh::moving()` to true seems the correct approach since it gives the correct `nearWallDist` (accuracy first), at the cost of negating the advantages of caching gradients. I will make a merge request soon.
For the long run however, we need to address this in a more general manner. As showcased above, not everything can be addressed by just playing with `fvMesh::moving()`. Ideally, we need a mechanism that performs updates when the mesh points change. This already exists in `MeshObject`.
Possible solutions:
1. `nearWallDist` to inherit from MeshObject; this will also create some consistency between `nearWallDist` and `wallDist`.
2. `solution` to clear all cached fields when mesh points change. It already knows the names of the cached fields (albeit not the types; but since we are talking about gradients, this can only be vol{Vector, Tensor}Field), so it can possibly inherit from MeshObject as well?
I would be glad to hear your suggestions. If you agree with the above, I can implement them but since this touches a wider scope than just optimisation, I guess there are things I have possibly missed when considering possible solutions.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2501MRF - non zero flux through walls in nonRotatingPatches2022-05-31T17:21:32ZnicolaMRF - non zero flux through walls in nonRotatingPatches<!--
*** 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
When including a patch in nonRotatingPatches, even if the patch is a wall, the flux through the patch is not 0. Indeed, printing phi from adjustPhi.C results in both an inflow and an outflow - which are equals and therefore cancel out, but in my opinion, should not be there. In a real-life problem, this might result in a conservation error in the case of a closed domain due to a small discrepancy between inflow and outflow.
### Steps to reproduce
print out flux through patches (e.g. replace lines 61 onwards of adjustPhi.C with
scalar massInStart = massIn;
scalar massOutStart = fixedMassOut;
forAll(phip, i)
{
if (phip[i] < 0.0)
{
massIn -= phip[i];
}
else
{
fixedMassOut += phip[i];
}
}
Info << "Mass in " << phip.patch().name() << endl;
Info << "equal to " << massIn- massInStart << endl;
Info << "Mass out " << phip.patch().name() << endl;
Info << "equal to " << fixedMassOut - massOutStart << endl;
and simpleFoam on the attached tutorial (modified from mixerVessel2DAMI)
[mixer2D.tar.gz](/uploads/669fe555e60f827e316d46b2408ff233/mixer2D.tar.gz)
### What is the expected *correct* behavior?
I would expect phi equal to 0 both inflow and outflow
### Environment information
OpenFOAM v2112
### Possible fixes
I tried to fix the issue by forcing flux to 0 in MRFZoneTemplates.C on the excludedFaces, but I don't believe this is correct.
<!--
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/2500Linear solver residual tolerances should not always be normalized2022-11-17T15:36:59ZCarsten ThorenzLinear solver residual tolerances should not always be normalized### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the ...### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the calculated residual is normalized with an estimate of the scale of the problem, which is computed from an initial guess for the solution and the RHS of the equation system. Actually, this turns the "absolute" tolerance into some kind of relative tolerance.
This is helpful (though misleading), if the expected absolute values of the residuals are unknown to the user. It is a disadvantage, if the expected absolute errors are known.
Thus it is proposed to optionally switch of the normalization of the residuals. A proposed patch is attached.
IMHO, the current specification of a tolerance and a relTol in the solver dictionary is weird, because actually both tolerances are compared to normalized residuals in the code. One by some properties of the equation system, the other by the initial residual. The treatment in the code "looks" different, but actually both variants are normalizations. But cleaning this up would require larger changes in the linear solvers, that I didn't want to tackle.
### Target audience
If the expected residuals and tolerances are well known, it is beneficial to use absolute tolerances for the solvers and not normalized ones, because it enhances the performance. Example: Transient tracer transport. In a simulation period with no or few tracer in the system, in the current implementation the normalization factor is near zero. Thus, the normalization of the residuals with "near zero" results in excessive iterations to reach the tolerance. The acquired accuracy is gained at high cost and might be unnecessary, if later in the transient development, at a much higher level of tracer concentrations, the interesting things happen.
### Proposal
Make the normalization of residuals a user choice. The proposed patch is an enhancement in lduMatrix::solver::normFactor . A user specified "residualNormalization" can then be added to the solver dictionary. If omitted, the old behaviour is retained. If set to "none", the normalization method returns "1", i.e. normalization is switched off. The currently implemented method is also available as axbScaling". For future use, other choices can easily be added.
### What does success look like, and how can we measure that?
Problem: The necessary effort (i.e. iterations) for the linear solvers should depend on the dynamics of the physical processes. The current normalization hinders that.
Example:
Unzip the example and run scalarTransportFoam. It is a simple example for a tracer transport, with a tracer injection starting at t=0.1 s. In the time < 0.1 s, only the initial value of tracer is in the system (very small) and is unchanged. Thus the solver should spend minimal effort. In the current implementation, the first initial residual is rescaled to 1 and unexplicably drops until t=0.1 s. The linear solver spends 5-8 unnecessary iterations in each time step. This is unwanted. After the tracer injection started, the number of iterations stays in the same range, while it should be higher then.
With the patch: Uncomment "residualNormalization" in system/fvSolution/solvers and re-run scalarTransportFoam.
Result: The solver spends zero iterations before the injection starts, because the initial residual are very low. After injection (t=0.1s), the iterations increase.
### Links / references
Example:
[o2112_example_scalarTransportFoam.zip](/uploads/dc6ab6eff55251eae6a76053b5a2517c/o2112_example_scalarTransportFoam.zip)
Patches:
[o2112_patches.zip](/uploads/6b0df79bd3107781b4b56ec62d53b6f6/o2112_patches.zip)
### Funding
The requested functionality has been implemented and tested. Both are attached (see above).
The diff of lduMatrixSolver.C is here:
[diff.txt](/uploads/d9e1075ca5bac7253409594edbe3ca44/diff.txt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2499odd behaviour with ensightWrite and manifold cells2022-06-02T07:18:48ZMark OLESENodd behaviour with ensightWrite and manifold cellsraised in EP1884raised in EP1884Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2498typo in description2022-06-08T13:16:08ZMatej Formantypo in descriptionin the description of Function object
`src/functionObjects/field/Curle/Curle.H`
Appears in dev as well as in master and in the oxygen online.
input and output keywords should be `point` not `points`in the description of Function object
`src/functionObjects/field/Curle/Curle.H`
Appears in dev as well as in master and in the oxygen online.
input and output keywords should be `point` not `points`https://develop.openfoam.com/Development/openfoam/-/issues/2497multizone group2022-05-30T09:11:18ZPrashant Sonakarmultizone groupcontinuation of topic from #2484
could be useful to specify 'inGroups' as an optional parameter for set-to-zone topo actions. Probably no future naming conflicts with that as a keyword, but open to other ideas (@andy @kuti @Mattijs @Ser...continuation of topic from #2484
could be useful to specify 'inGroups' as an optional parameter for set-to-zone topo actions. Probably no future naming conflicts with that as a keyword, but open to other ideas (@andy @kuti @Mattijs @Sergio)https://develop.openfoam.com/Development/openfoam/-/issues/2496sha1 error for OpenFOAM 2106 on Ubuntu 22.042022-06-24T16:35:13Zt Rocksha1 error for OpenFOAM 2106 on Ubuntu 22.04Hi,
I am trying to compile OpenFOAM in Ubuntu 22.04.
I had to install g++ and gcc 9.4.0 (Same version I used in Ubuntu 20.04)
With:
```
sudo apt install build-essential sudo apt-get install gcc-9 g++-9
sudo update-alternatives --i...Hi,
I am trying to compile OpenFOAM in Ubuntu 22.04.
I had to install g++ and gcc 9.4.0 (Same version I used in Ubuntu 20.04)
With:
```
sudo apt install build-essential sudo apt-get install gcc-9 g++-9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-9 9 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-9 9
sudo update-alternatives --config gcc # To select gcc version [9.4.0]
sudo update-alternatives --config g++ # To select g++ version[9.4.0]
```
I am able to compile the code. But when I try to run simpleFoam, I get the following error:
```
--> FOAM FATAL IO ERROR: (openfoam-2106 patch=211215)
error in IOstream "sha1" for operation Foam::Ostream& Foam::operator<<(Foam::Ostream&, int32_t)
```
The result from `foamInstallationTest` is:
```
Executing foamInstallationTest
Basic setup :
-------------------------------------------------------------------------------
OpenFOAM: OpenFOAM-v2106
ThirdParty: ThirdParty-v2106
Shell: bash
Host: tRock-OMEN-by-HP-Laptop
OS: Linux version 5.15.0-33-generic
-------------------------------------------------------------------------------
Main OpenFOAM env variables :
-------------------------------------------------------------------------------
Environment FileOrDirectory Valid Crit
-------------------------------------------------------------------------------
$WM_PROJECT_USER_DIR /home/tRock/OpenFOAM/tRock-v2106 yes no
$WM_THIRD_PARTY_DIR /home/tRock/OpenFOAM/ThirdParty-v2106 yes maybe
$WM_PROJECT_SITE [env variable unset] no
-------------------------------------------------------------------------------
OpenFOAM env variables in PATH :
-------------------------------------------------------------------------------
Environment FileOrDirectory Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR /home/tRock/OpenFOAM/OpenFOAM-v2106 yes yes yes
$FOAM_APPBIN .../platforms/linux64GccDPInt32Debug/bin yes yes yes
$FOAM_SITE_APPBIN .../platforms/linux64GccDPInt32Debug/bin no no
$FOAM_USER_APPBIN .../platforms/linux64GccDPInt32Debug/bin no no
$WM_DIR /home/tRock/OpenFOAM/OpenFOAM-v2106/wmake yes yes often
-------------------------------------------------------------------------------
OpenFOAM env variables in LD_LIBRARY_PATH :
-------------------------------------------------------------------------------
Environment FileOrDirectory Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN .../platforms/linux64GccDPInt32Debug/lib yes yes yes
$FOAM_SITE_LIBBIN .../platforms/linux64GccDPInt32Debug/lib no no
$FOAM_USER_LIBBIN .../platforms/linux64GccDPInt32Debug/lib no no
$FOAM_EXT_LIBBIN ...v2106/platforms/linux64GccDPInt32/lib yes yes maybe
$MPI_ARCH_PATH /usr/lib/x86_64-linux-gnu/openmpi yes yes yes
-------------------------------------------------------------------------------
Software Components
-------------------------------------------------------------------------------
Software Version Location
-------------------------------------------------------------------------------
flex 2.6.4 /usr/bin/flex
make 4.3 /usr/bin/make
wmake 2106 /home/tRock/OpenFOAM/OpenFOAM-v2106/wmake/wmake
gcc 9.4.0 /usr/bin/gcc
g++ 9.4.0 /usr/bin/g++
-------------------------------------------------------------------------------
icoFoam exists ...M-v2106/platforms/linux64GccDPInt32Debug/bin/icoFoam
Summary
-------------------------------------------------------------------------------
Base configuration ok.
Critical systems ok.
Done
```
The compilation log is attached to this post.
What is sha1? And how can I fix this?
[log.linux64GccDPInt32Debug](/uploads/5d0fc0717503cabffe1e6828a0b73283/log.linux64GccDPInt32Debug)https://develop.openfoam.com/Development/openfoam/-/issues/2495Out-of-source install possible?2022-06-14T07:59:01ZVictor EijkhoutOut-of-source install possible?Is it possible to install OpenFOAM not-in-the-source-directory, or at least so that it copies all generated files to a prefix directory? The `Allwmake` command claims to accept a directory argument but I don't see what it does.Is it possible to install OpenFOAM not-in-the-source-directory, or at least so that it copies all generated files to a prefix directory? The `Allwmake` command claims to accept a directory argument but I don't see what it does.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2494BUG: redistributePar -reconstruct: Lagrangian fields are not reconstructed2022-06-27T07:58:22ZKutalmış BerçinBUG: redistributePar -reconstruct: Lagrangian fields are not reconstructedIn `$FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek`, run:
```
./Allclean
./Allrun-parallel
reconstructPar -latestTime
ls 0.5/lagrangian/limestoneCloud1/
```
yields: `active age coordinates Cp d dTarget nParticle or...In `$FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek`, run:
```
./Allclean
./Allrun-parallel
reconstructPar -latestTime
ls 0.5/lagrangian/limestoneCloud1/
```
yields: `active age coordinates Cp d dTarget nParticle origId origProcId positions rho T tTurb typeId U UCorrect UTurb`
Then:
```
./Allclean
./Allrun-parallel
mpirun -np 4 redistributePar -parallel -reconstruct -latestTime
ls 0.5/lagrangian/limestoneCloud1/
```
yields: `coordinates positions`
Note-1: Tested dev c6d9c0317d, v2112 14aeaf8dab, v2106 c15bfde3cb
Note-2: `redistributePar -decompose` works as expected.
@Mattijs @mark