add support for mingw cross-compilation

@Pawan @Roger

mentioned in commit fc631e56

Misc Notes

• updates for endian, bessel, regex already made to develop

  • c18d0dc6
  • 2cf7d700
  • d17ce57e
  • 638a1efd

• Skip compilation of wmake/src/Allmake in favour of copy/sync from existing binaries. Eg,

rsync -aP wmake/platforms/linux64Gcc/ wmake/platforms/linux64Mingw

This provides linux (not windows) executables for the host system. Otherwise you'd get the target system (windows) binaries for wmdepend etc and that doesn't work very well for us. Could theoretically provide a scripted workaround for this, but it doesn't occur very often and thus handle manually.

mentioned in commit ab2e1002

mentioned in commit f3425b53

mentioned in commit 124a3516

mentioned in commit bf5af092

mentioned in commit 8413f620

mentioned in commit bca575da

mentioned in commit d933a18a

mentioned in commit 3f1a5802

mentioned in commit 49cb728c

mentioned in commit c3ee4a6f

mentioned in commit af9a7b29

made the issue visible to everyone

mentioned in commit 0d672c21

mentioned in commit 40426850

mentioned in commit 570d900d

mentioned in commit 947646de

mentioned in commit ee845da8

mentioned in commit 3f36a509

mentioned in commit 0b16776b

mentioned in commit 031fa57f

mentioned in commit 763b2ece

off by one in GetEnvironmentVariable CWD sizing (as discussed)

regular expression in fvSolution (pitzDaily case) does not work

mentioned in commit 2827a57b

snappyHexMesh with implict option i.e using .eMesh does not work

--> FOAM FATAL ERROR: Cannot read file "C:/Users/pgh.ESI-INTERNAL/Desktop/motorBike-1/constant/triSurface/motorBike.eMesh" From function virtual bool Foam::fileFormats::edgeMeshFormat::read(const Foam::fileName&) in file edgeMesh/edgeMeshFormats/edgeMesh/edgeMeshFormat.C at line 82. FOAM exiting

mentioned in commit d5b1e5a0

mentioned in commit 267a8464

mentioned in commit b585b98a

TJunction( compressible/rhoPimpleFoam/RAS/TJunction)
case was failing earlier as it was not able to find "viscousDissipation"
and we need to add libs(libfvOption.dll) line in system/controlDict .
Now with latest fix this is not required. Tutorial can run directly as it is

@mark ptscotch compilation failed for me .

In file included from dummysizes.c:90:0: common.h:108:28: fatal error: mpi.h: No such file or directory compilation terminated.

Probably need to check if your mpi (eg, MSMPI) is being found properly. Does $MPI_ARCH_PATH point to anything useful?

To use scotch decomposition method , i need to include libs("libscotchDecomp.dll"). By default, it does not recognize scotch method.

Is this decomposePar or something else?

Yes , decomposePar.

Odd, that shouldn't be (if you rebuilt after the commit b585b98a).

In my build/linux64MingwDPInt32Opt/applications/utilities/parallelProcessing/decomposePar/options file I have this type of content:

EXE_INC += -DFOAM_DLOPEN_LIBS='"finiteArea","finiteVolume","meshTools","lagrangian","dynamicMesh","regionModels","genericPatchFields","decompose","decompositionMethods","kahipDecomp","metisDecomp","scotchDecomp"'

If you don't have that, perhaps you are still using an older compilation.

Thanks Mark. I can see in my option file these three not included. kahipDecomp","metisDecomp","scotchDecomp"' is not included. I have taken update and compiling it again

If you read the notes carefully on the commit, you'll also see that this approach can be a bit sticky. That is to say you may need to wclean the applications first to get the proper creation of the options files.

I took latest update and decomposePar work fine with scotch.

Regarding ptscotch, I still face same issue i.e unable to compile . MPI_ARCH_PATH point to msmpi and path is OK. libPstream compiled without any issue .

I am using msy2 terminal to run tutorials. I am able to source etc/bashrc file.
However to run Allrun scripts I need to do two things manually.

1. ADD path of lib folder in PATH environment variable . In windows, all lib folder need to be added to PATH environment variable .

[EDIT] 2)need to change mpirun to mpiexec in RunFunctions. also np need to be replaced by "n"

mpirun -np 2 simpleFoam -parallel (Linux)

mpiexec -n 2 simpleFoam -parallel (windows)

Feature request:It will be great, if OpenFOAM can select, mpiexec for windows automatically to run tutorials. Regarding add path of LIB to PATH env for

mentioned in commit 3c505688

Hi Mark

Thanks for commit 3c505688 . I realized that in windows with mpiexec , we use -n instead of -np
i.e mpiexec -n 2 simpleFoam -parallel (windows). Can you please add this one too .

mentioned in commit 7c584292

Hi Mark

timeActivatedFileUpdate functionObjects does not work as expected . I can see , it is being executed
and it copy file i.e fvSchmes_2ndOrder but it cannot copy to desired name schemes but copied to fvSchemes3090 in system folder. Number digit is different every time. This number is actually process pid.

Greetings to all,

I've been following this report and haven't had time to investigate deeper on how things are going.

But on this issue with the timeActivatedFileUpdate I can give a bit of information, because I've stumbled on this on Windows with blueCFD-Core as well, so I'm assuming it's the same exact problem:

1. In the method updateFile(): https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/functionObjects/utilities/timeActivatedFileUpdate/timeActivatedFileUpdate.C#L72 - there is first a copy and then a move.

2. The move was intended to make the transfer as quick as possible, since it's just a filesystem metadata tweak; but on Windows, the file to be replaced is somehow still open and Windows does not like that opened files are replaced (part of Windows' multiple safety measures).

3. So either the file stops being left open (although I thought that they were closed in the first place after reading them, maybe a destructor is failing?) or the replacement+trigger is done in some other way.

Best regards, Bruno

Might an explicit close() help? Seems like much the same thing as the destructor is supposed to do.

@mark I haven't studied the IO dictionary code properly, so I assumed that the file closure was handled at destruction...

Either way, an explicit close() will require that an open(...) is done soon after... and I don't remember if the IO notify feature relies on an open file handle or not...

mentioned in commit 81c96a2d

closed

mentioned in commit fd0282f2

mentioned in commit 90f039fa

mentioned in commit 717a3e59