Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-05-29T05:39:48Zhttps://develop.openfoam.com/Development/openfoam/-/issues/329mapFields command not found2018-05-29T05:39:48ZAdminmapFields command not foundWhen working through the Cavity tutorial, invoking the command mapFields yields the error message command not found.
~/OpenFOAM/OpenFOAM-v1606+$ mapFields -help
mapFields: command not foundWhen working through the Cavity tutorial, invoking the command mapFields yields the error message command not found.
~/OpenFOAM/OpenFOAM-v1606+$ mapFields -help
mapFields: command not foundhttps://develop.openfoam.com/Development/openfoam/-/issues/2367mapFields not working with collated file format2022-03-23T17:07:32ZFilippo GiussanimapFields not working with collated file format### Summary
mapFields (serial application) fails to map from parallelSource to parallelTarget if the fileHandler format is collated. On the other hand the same applications works if the fileHandler is uncollated.
### Steps to reproduc...### Summary
mapFields (serial application) fails to map from parallelSource to parallelTarget if the fileHandler format is collated. On the other hand the same applications works if the fileHandler is uncollated.
### Steps to reproduce
I started from the incompressible/simpleFoam/backwardFacingStep2D with the collated specified in the controlDict and decomposed in 8 subdomain using hierarchical decomposition with n (4 2 1) . I run 30 iterations. ( this is my collatedSourceCase)
I then created a copy of this tutorial and only run the same blockMesh and run the decomposition with collated format. (this my collatedTargetCase).
Then inside the folder of the collatedTargetCase I execute the command :
mapFields "path_of_sourceCaseCollated" -mapMethod interpolate -parallelSource -parallelTarget -sourceTime latestTime
I tried with all the available interpolation method but it failed every time in the same way
### What is the current *bug* behaviour?
It fails when It tries to read a block of the targetCollatedCase.
Since the mesh between the 2 cases is exactly the same, so are the meshes of the subdomains since the decomposition is deterministic.
As you may see from the log below, it mapped correctly the first block but then it fails when it tries to map the second block.
This happens because the original target collated file is overwritten so it loses all the info about the other blocks. So, the the next time the program tries to read the target collated field it cannot find the others blocks.
As a proof I suggest to run the example I mentioned and to have a look at the p field collated file and you will notice that the other blocks are missing.
### What is the expected *correct* behaviour?
The original collated target case should be updated when the write happens at the end of each mapping loop. This means that the blocks should be moved and the number of bytes updated. This is probably the most difficult part.
### Relevant logs and/or images
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "sourceCaseCollated"
Target: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "targetCaseCollated"
Mapping method: interpolate
Create databases as time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Overriding fileHandler to collated
I/O : collated [unthreaded] (maxThreadFileBufferSize = 0).
Writing may be slow for large file sizes.
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Source processor 0
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Source time: 30
Target time: 0
mesh size: 2567
Target processor 0
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
mesh size: 2567
Mapping fields for time 30
interpolating p
interpolating nut
interpolating k
interpolating omega
interpolating U
Target processor 1
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
mesh size: 2567
Mapping fields for time 30
interpolating p
--> FOAM FATAL IO ERROR: (openfoam-2112)
incorrect first token, expected <int>, found on line 25: error
file: processors8/0/p at line 25.
From Foam::Istream& Foam::List<T>::readList(Foam::Istream&) [with T = char]
in file primitives/chars/lists/charList.C at line 103.
FOAM exiting
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112
Operating system : centos 8
Compiler : gcc 8.4.0
### Possible fixes
adding functionality to the decomposedBlockData class to write multiple times on the collated target field without loosing previous informationhttps://develop.openfoam.com/Development/openfoam/-/issues/2057mapFieldsPar not execute on windows OS with source path in forward slashes2021-12-10T13:14:16ZYogesh DeshmukhmapFieldsPar not execute on windows OS with source path in forward slashes<!--
*** 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 -->
while executing mapFieldPar on windows 10 OS with openFOAM2012 gives error , if source path content forward slashes
### Steps to reproduce
Create two openFAOM directories which can be mapped. while giving path such as source path with forward slashes.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Example case attached.
Unzip the attachment.
See two log files namely backward_shlash.log and forward_shlash.log inside mapField_Window_Forward_Slash_Issue\run_win folder.
"backward_shlash.log" this log file contains log with source path given with backward slashes.
"forward_shlash.log" this log file contains log with source path given with forward slashes.
<!--
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?
mapFiledsPar fail to execute
<!-- What actually happens -->
### What is the expected *correct* behavior?
mapFiledsPar should get execute
<!-- What you should see instead -->
user need to manually change the path which is very cumbersome.
### Relevant logs and/or images
See two log files namely backward_shlash.log and forward_shlash.log inside mapField_Window_Forward_Slash_Issue\run_win folder.
<!--
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 : 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 : Windows 10
- 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
-->
[mapField_Window_Forward_Slash_Issue.zip](/uploads/3576b46b2759a544d3843da67ad27796/mapField_Window_Forward_Slash_Issue.zip)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2179mapFieldsPar problem when running in Parallel2023-09-06T09:01:10ZPablo UsyaopinmapFieldsPar problem when running in Parallel<!--
*** 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 executing the mapFieldsPar in parallel trying to map one box with 2 elements into another box of 2 or 4, or more elements I encounter a out of index error. When executing the same in serial it works fine.
### Steps to reproduce
In the target source I execute the following:
mpirun -np 2 mapFieldsPar /decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime -parallel
### What is the current *bug* behaviour?
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2006 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 5e660c36e9-20201103 OPENFOAM=2006 patch=201012
Arch : "LSB;label=32;scalar=64"
Exec : mapFieldsPar /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime -parallel
Date : Aug 07 2021
Time : 10:09:18
Host : pablo-XPS-13-9370
PID : 13775
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_trialWithLessElements
nProcs : 2
Hosts :
(
(pablo-XPS-13-9370 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_copyWithLessTime"
Target: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_trialWithLessElements"
Create databases as time
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime
nProcs : 2
Hosts :
(
(pablo-XPS-13-9370 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
Overriding DebugSwitches according to controlDict
meshToMesh 2;
Source time: 0
Target time: 0
Create meshes
Source mesh size: 2 Target mesh size: 2
Creating and mapping fields for time 0
Creating mesh-to-mesh addressing for region0 and region0 regions using cellVolumeWeight
From Foam::label Foam::meshToMesh::calcDistribution(const Foam::polyMesh&, const Foam::polyMesh&) const
in file meshToMesh/meshToMeshParallelOps.C at line 70
Meshes split across multiple processors
meshToMesh: Using AABBTree method
From Foam::autoPtr<Foam::mapDistribute> Foam::meshToMesh::calcProcMap(const Foam::polyMesh&, const Foam::polyMesh&) const
in file meshToMesh/meshToMeshParallelOps.C at line 176
Determining extent of src mesh per processor:
proc bb
0 2{(-0.0003 -0.0003 -0.0003) (0.0203 0.0203 0.0103)}
1 2{(-0.0003 -0.0003 0.0097) (0.0203 0.0203 0.0203)}
[0] Of my 1 target cells I need to send to:
[0] proc cells
[0] 0 1
[0] 1 1
[1] Of my 1 target cells I need to send to:
[1] proc cells
[1] 0 1
[1] 1 1
[0] tgtProc:0 sending tgt cell 0[0] to srcProc 0
[1] tgtProc:1 sending tgt cell 0[1] to srcProc 0
[0] tgtProc:0 sending tgt cell 0[0] to srcProc 1
[1] tgtProc:1 sending tgt cell 0[1] to srcProc 1
[0] Target mesh send sizes[0]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[0] Target mesh send sizes[1]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[1] Target mesh send sizes[0]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[1] Target mesh send sizes[1]: points=8, faces=6, nInternalFaces=0, faceOwn=6, faceNbr=6, cellIDs=1
[0] Additional internal face between procs:0 and 1 across local face 0
[0] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[0] Additional internal face between procs:0 and 1 across local face 0
[1] Additional internal face between procs:0 and 1 across local face 0
[0] proc 0 inserting face:0 connection between owner 0 and neighbour 0
[0] proc 1 inserting face:1 connection between owner 1 and neighbour -2
[1] proc 0 inserting face:0 connection between owner 0 and neighbour 0
[1] proc 1 inserting face:1 connection between owner 1 and neighbour -2
[1] proc 1 inserting face:2 connection between owner 1 and neighbour -2
[0] proc 1 inserting face:2 connection between owner 1 and neighbour -2
[0]
[0]
[0] --> FOAM FATAL ERROR:
[0] index 9 out of range [0,9]
[0]
[0] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[0] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[0]
FOAM parallel run aborting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] index 9 out of range [0,9]
[1]
[1] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[1] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[1]
FOAM parallel run aborting
[0]
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] index 9 out of range [0,9]
[1]
[1] From void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::face; Foam::label = int]
[1] in file /home/pablo/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H at line 138.
[1]
[1]
[0] #0 [1] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OSspecific/POSIX/printStack/printStack.C:237
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OSspecific/POSIX/printStack/printStack.C:237
[1] #1 Foam::error::exitOrAbort(int, bool)[0] #1 Foam::error::exitOrAbort(int, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:265
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:265
[1] #2 Foam::error::abort()[0] #2 Foam::error::abort() at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:307
[0] #3 at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/error.C:307
[1] #3 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>)Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #4 in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #4 Foam::UList<Foam::face>::checkIndex(int) constFoam::UList<Foam::face>::checkIndex(int) const in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #5 Foam::UList<Foam::face>::operator[](int) in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #5 Foam::UList<Foam::face>::operator[](int) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H:251
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/OpenFOAM/lnInclude/UListI.H:251
[0] #6 Foam::meshToMesh::distributeAndMergeCells(Foam::mapDistribute const&, Foam::polyMesh const&, Foam::globalIndex const&, Foam::Field<Foam::Vector<double> >&, Foam::List<Foam::face>&, Foam::List<int>&, Foam::List<int>&, Foam::List<int>&) const[1] #6 Foam::meshToMesh::distributeAndMergeCells(Foam::mapDistribute const&, Foam::polyMesh const&, Foam::globalIndex const&, Foam::Field<Foam::Vector<double> >&, Foam::List<Foam::face>&, Foam::List<int>&, Foam::List<int>&, Foam::List<int>&) const at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMeshParallelOps.C:860 (discriminator 1)
[0] #7 Foam::meshToMesh::calculate(Foam::word const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMeshParallelOps.C:860 (discriminator 1)
[1] #7 Foam::meshToMesh::calculate(Foam::word const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:466 (discriminator 1)
[1] #8 Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:466 (discriminator 1)
[0] #8 Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:832
at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:832
[1] #9 Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, Foam::meshToMesh::procMapMethod const&, bool)[0] #9 Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&, Foam::meshToMesh::procMapMethod const&, bool) at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:980
[0] #10 at ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/src/sampling/meshToMesh/meshToMesh.C:980
[1] #10 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #11 in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #11 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[0] #12 __libc_start_main in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
[1] #12 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
[0] #13 in /lib/x86_64-linux-gnu/libc.so.6
[1] #13 ?? in ~/BuildOpenFoamPlus/OpenFoamGit/openfoam/platforms/linux64Gcc75DPInt32Debug/bin/mapFieldsPar
```
### What is the expected *correct* behavior?
When running in serial the result is as expected:
```
mapFieldsPar /decayIsoTurb4.1_copyWithLessTime -sourceTime latestTime
```
```
Source: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_copyWithLessTime"
Target: "/home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric" "decayIsoTurb4.1_trialWithLessElements"
Create databases as time
I/O : uncollated
Case : /home/pablo/Desktop/ApplicationRuhr/Data/paperIlana/twoPointCorrEnric/decayIsoTurb4.1_copyWithLessTime
nProcs : 1
Overriding DebugSwitches according to controlDict
meshToMesh 2;
Source time: 0
Target time: 0
Create meshes
Source mesh size: 2 Target mesh size: 2
Creating and mapping fields for time 0
Creating mesh-to-mesh addressing for region0 and region0 regions using cellVolumeWeight
Source size = 2
Target size = 2
Overlap volume: 8e-06
interpolating onto existing field U
ExecutionTime = 0.03 s ClockTime = 0 s
End
```
### Environment information
- OpenFOAM version : v2006 and v2012
- Operating system : Ubuntu 18.04 and OpenSuse 15.2
- Hardware info :
- Compiler : gcc7.5
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2944mapFieldsPar - source and target swapped - WIP code2023-09-01T11:13:55ZPrashant SonakarmapFieldsPar - source and target swapped - WIP codeDeveloped for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Developed for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/357mapFields, setFields, dsmcInitialise not working on install2018-05-29T05:39:49ZAdminmapFields, setFields, dsmcInitialise not working on installI have recently installed OpenFOAM v1606+ on my ubuntu 16.10 machine. I followed every step on - http://openfoam.com/download/install-source.php and then went on to the build guide - http://openfoam.com/code/build-guide.php
The solve...I have recently installed OpenFOAM v1606+ on my ubuntu 16.10 machine. I followed every step on - http://openfoam.com/download/install-source.php and then went on to the build guide - http://openfoam.com/code/build-guide.php
The solvers has seemed to have installed fine but some applications (as when I do i.e. icoFoam -help or dsmcFoam -help, it doesn't say command not found) hasn't installed it seems. I have been doing some basic OpenFOAM tutorials and have come across that mapFields (Lid driven Cavity tutorial) and setFields (Dambreak tutoria) and dsmcInitialise (dsmcFoam tutorial) isn't working, which means I can't move forward with the tutorials and in turn my research.
[Edit: I removed the listing of Allwmake, since it doesn't help]
I don't know if this is the source of the error, I really want my OpenFOAM to work, I have wasted one whole day reinstalling it as I thought it would somehow fix itself once I remove and re-install it again but it hasn't.https://develop.openfoam.com/Development/openfoam/-/issues/1167mapFields : zero values on processor interface2021-07-06T15:17:17ZPrashant SonakarmapFields : zero values on processor interfacecross reference: EP#814cross reference: EP#814AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/3090mapped boundary conditions in combination with partial mesh motion2024-01-31T13:13:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapped boundary conditions in combination with partial mesh motion### Functionality to add/problem to solve
When there is any mesh motion (even if the points are kept the same) all the inter-region mapping information is thrown away. Instead keep the mapping information if the actual coupling location...### Functionality to add/problem to solve
When there is any mesh motion (even if the points are kept the same) all the inter-region mapping information is thrown away. Instead keep the mapping information if the actual coupling locations stay the same.
### Target audience
moving mesh cases with mapping where the mapping is inside a static portion of the mesh.
### Proposal
Check actual locations
### What does success look like, and how can we measure that?
Speed up.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2688mappedPatchBase is not updated if for topochange after commit 945405c32dca568...2023-02-08T02:40:51ZDarrin StephensmappedPatchBase is not updated if for topochange after commit 945405c32dca5682827356d29fa5557abb3d88d8### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and libra...### Summary
After a recent commit (945405c32dca5682827356d29fa5557abb3d88d8) mappedPatchBase isn't recalculating the map after a topological change to the mesh.
### Steps to reproduce
I'm using the chtMultiRegionDyMFoam solver and library from https://develop.openfoam.com/Henning86, although it has been updated to work with V2212.
My fork of this can be found here https://github.com/darrinl2t/multiDimAMR/tree/v2212
1. Clone the repository given above.
2. Source OF-v2212
3. Execute the Allwmake script from the multiDimAMR repository
4. Run the heatedRoom tutorial. This will crash at 0.8s when the mesh is changed.
### Example case
An example case is heatedRoom tutorial in the repository link provided above.
### What is the current *bug* behaviour?
The solver crashes after the mesh has been changed. I have isolated this to the Foam::mappedPatchBase::upToDate() function in mappedPatchBaseI.H not returning false after the sampleMesh has been changed.
### What is the expected *correct* behavior?
The expected behaviour is the solver should run. To confirm this checkout commit 013f3cccc41a25b12eb13b32e5e07c09bb3cac3c from the OpenFOAM repository, this is the commit before the changes to mappPatchase. Compile with this commit and recompile the multDimAMR library and solver.
Run the tutorial with the code at this commit, the solver will run fine and the mesh will be adapted to the fluid temperature as expected.
### Environment information
OpenFOAM version : v2212
### Possible fixes
I don't have a fix for this. What I have determined is that after the fluid side mesh has been changed its eventNo() isn't updated, so the test sampleMesh().upToDatePoints(updateSampleMeshTime() returns True when it should be false.https://develop.openfoam.com/Development/openfoam/-/issues/1676mappedPatchBase is not updated if the sampleMesh is topochanging2022-11-02T20:33:08ZHenning ScheuflermappedPatchBase is not updated if the sampleMesh is topochanging<!--
*** 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 ...<!--
*** 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 -->
This could be an issue in the imaginable solver: chtMultiRegionDyMFoam.
mappedPatchBase should recalculate the addressing to the sampledPatch if the sampledMesh changes its topology. The addressing should also be recalculated if the mesh owning the patch changes its topolology. This would be the case with dynamicMotionSolverFvMesh with e.g. displacementLaplacian motion solver. In case of AMR, the fields are remapped after calling mappedPatchBase::clearOut
### 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
-->
mappedPatchBaseI.H:
```
inline const Foam::mapDistribute& Foam::mappedPatchBase::map() const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = sampleMesh().topoChanging() || thisMesh.topoChanging();
if (topoChange)
{
mapPtr_.clear();
}
if (mapPtr_.empty())
{
calcMapping();
}
return *mapPtr_;
}
inline const Foam::AMIPatchToPatchInterpolation& Foam::mappedPatchBase::AMI
(
bool forceUpdate
) const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = sampleMesh().topoChanging() || thisMesh.topoChanging();
if (topoChange || forceUpdate)
{
AMIPtr_.clear();
}
if (AMIPtr_.empty())
{
calcAMI();
}
return *AMIPtr_;
}
```
mappedPatchBase.C:
```
const Foam::autoPtr<Foam::searchableSurface>& Foam::mappedPatchBase::surfPtr()
const
{
const polyMesh& thisMesh = patch_.boundaryMesh().mesh();
bool topoChange = thisMesh.topoChanging();
if (topoChange)
{
surfPtr_.clear();
}
const word surfType(surfDict_.lookupOrDefault<word>("type", "none"));
if (!surfPtr_.valid() && surfType != "none")
{
...
...
```https://develop.openfoam.com/Development/openfoam/-/issues/943mapped patched averaging should be an optional entry2018-07-18T16:22:10ZMark OLESENmapped patched averaging should be an optional entryv1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1864mapPolyMesh constructor from mesh incorrect2020-10-12T11:50:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapPolyMesh constructor from mesh incorrectMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/748mapToSurface template substitution problem2018-03-06T10:49:12ZAdminmapToSurface template substitution problemThe finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Fo...The finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Foam::volSurfaceMapping::mapToSurface(const Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary&)’`
`note: candidate: template<class Type> Foam::tmp<Foam::Field<Type> > Foam::volSurfaceMapping::mapToSurface(const typename Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>::Boundary&) const
tmp<Field<Type>> mapToSurface`https://develop.openfoam.com/Development/openfoam/-/issues/563markup for pstream token types is fragile2017-08-10T12:57:02ZMark OLESENmarkup for pstream token types is fragileThis seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase...This seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase by one. This made `DOUBLE_SCALAR` receive a value of 9.
In `UOPstream::write(double)` this enumeration value is written as a character, which unfortunately corresponds to Tab and thus gets swallowed as a whitespace character. After this, the receiving end hasn't much chance.
I think that we should be invoking `writeToBuffer(char)` directly instead of using things like `write(char(token::DOUBLE_SCALAR))` - should be more reliable.
@Mattijsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1653MarshakRadiation bc not mapped correctly2020-04-08T05:54:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMarshakRadiation bc not mapped correctly<!--
*** 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 ...<!--
*** 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 -->
MarshakRadiation bc not mapped correctly. You can see this e.g. in redistributePar of a case with radiation and marshakRadiation bcs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with marshakRadiation bcs:
```
mpirun redistributePar -parallel -decompose
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1747mask handling in ensight surface reader2020-06-25T10:08:18ZMark OLESENmask handling in ensight surface readerNoted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.Noted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/428mass conservation problem in interCondensingEvaporatingFoam2017-04-18T13:40:34ZAdminmass conservation problem in interCondensingEvaporatingFoamDear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and...Dear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and a body limited by two heated plates.
At the inlet the liquid enters the domain, is heated, partially evaporates and leaves the domain via outlet.
The problem is that the mass is not conserved. There is approximately 6x larger mass flow of the liquid/vapor mixture at the outlet that at the inlet.
Please see the attached picture, which shows some filed values and integrated 'u_x*rho' over the inlet and outlet patch (u_x in normal to the inlet/outlet, so it gives mass flow).
![mass_conservation_problem](/uploads/392619e49f0b4f2972c607e84143be8f/mass_conservation_problem.png)
upper row of the figure shows the data for the inlet; the value "U_x_times_rho_inlet" in the table on the right corresponds to inlet mass flow
lower row of the figure shows the data for the outlet; the value "U_x_times_rho_outlet" in the table on the right corresponds to outlet mass flow
Regards
Jimhttps://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2368masterUncollated with #include inside decomposeParDict hangs2022-02-24T16:31:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commasterUncollated with #include inside decomposeParDict hangs<!--
*** 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 -->
#include a file in the decomposeParDict. Now any parallel run will hang when run with -fileHandler masterUncollated.
See https://exchange.openfoam.com/node/1828
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case. See above.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Hangs. Stuck in some gatherList when parsing the dictionary (on the master).
### 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 : v2112
### 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
-->
decomposeParDict is special - it gets read during startup to read any roots and the number of processors. At this point the dictionary reading is not yet 'set up' so it should disable any parallel communication. The #include statement in the decomposeParDict triggers parallel communication.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/200maxDeltaxyz changes missed in turbulence model upgrade2019-12-09T22:04:10ZAdminmaxDeltaxyz changes missed in turbulence model upgradeThe maxDeltaxyz LES delta behaviour was updated in version 2.3.x to correct excessive lengths being calculated at changes in mesh refinement, e.g. the 2:1 levels generated by snappyHexMesh. These changes were not included when moving to...The maxDeltaxyz LES delta behaviour was updated in version 2.3.x to correct excessive lengths being calculated at changes in mesh refinement, e.g. the 2:1 levels generated by snappyHexMesh. These changes were not included when moving to the templated turbulence structureVersion v1612AdminAdmin