add support for mingw cross-compilation

@Pawan @Roger

mentioned in commit fc631e564e8837b0312823f25aca32816d8196d8

Misc Notes

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

  • c18d0dc61cb590c49141231f88f46537533e7675
  • 2cf7d700b18d785a3beafe8809375011a69c55b6
  • d17ce57e291e29d0b3d89c9973bcc468a4e3d504
  • 638a1efd86f1b49822e66e02cb006fc63693098e

• 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 ab2e1002da4ee2cb688b63a065f40ddc8541c191

mentioned in commit f3425b5363b1c8eb6083494ead9074a4ab5c834b

mentioned in commit 124a351693b1694aab16c42f5630ec031e3370b5

mentioned in commit bf5af0929a4da238571ecc5052752bafe225f14d

mentioned in commit 8413f620607b2af84d39e4f2ffa519b57fb43112

mentioned in commit bca575daee2d74f251032b0f42e8e356f1b30cdd

mentioned in commit d933a18aa297cab5c88b41f336c02531307a4c07

mentioned in commit 3f1a5802681da0b63f721ed3938f74682683a155

mentioned in commit 49cb728c87d4be65402b3df00b3151f17f23dedf

mentioned in commit c3ee4a6f4b1bdacd16eb25c5b2509047dd427b0c

mentioned in commit af9a7b29416e1c2e0fe3b78d9b41b25e5ed6b0ad

made the issue visible to everyone

mentioned in commit 0d672c21ec185652cf88cb7c2190afbff7e31cc9

mentioned in commit 40426850a309657f6535f107c302d45d47b6425b

mentioned in commit 570d900de62a6fbf78bf6c1456ec4faaceebc82f

mentioned in commit 947646de0270e4f5955c13c7e639a32b5c3d7426

mentioned in commit ee845da89fd1e9f1e1df6adb267ea5653663ccfe

mentioned in commit 3f36a509b368124a74a7aed9aabbeb95f6659193

mentioned in commit 0b16776b442be0a429d00b8548072cb01ddf3271

mentioned in commit 031fa57fcf2bc232ae6ccd0d1792f33335cc813f

mentioned in commit 763b2eced7822d42eff40baf20b0510afe24c156

off by one in GetEnvironmentVariable CWD sizing (as discussed)

regular expression in fvSolution (pitzDaily case) does not work

mentioned in commit 2827a57b1a2cc81b9432b088640a08db0e93cacf

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 d5b1e5a06d4c0ca5389904c5e76cce05ac7fd096

mentioned in commit 267a846424820f8933f268531f7aa6bcb2f07106

mentioned in commit b585b98a034c9190f1d7e10366fb0e6c4a98ffb0

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 b585b98a034c).

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 3c50568880ac1a5b49395b7a20b93c2d5bd6632c

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 7c584292f44238f05eac1566a23b67f6f135c242

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

By Bruno Santos on 2019-06-06T09:32:46 (imported from GitLab project)

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...

By Bruno Santos on 2019-06-06T13:01:41 (imported from GitLab project)