twoPhaseCompressibleTurbulenceModels compile error

[NablaCFD]

Firstly, Thank you very much for taking OpenFOAM Technology into Windows platform. This release will make more people understand the fascinating and wonderful CFD technology of OpenFOAM.

I download the BlueCFD-core-2016 installer, and install it in C directory of Win 10 Entr. Then I use "git pull" update to latest source codes. While I compiled the code, the following error exist.

I suspect the file name is maybe too long. but I can not find workable solution.

"+ wmake libso twoPhaseCompressibleTurbulenceModels Make.win
/home/ofuser/blueCFD/OpenFOAM-4.x/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels
x86_64-w64-mingw32-g++ -std=c++0x -Dmingw_w64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -DWIN64 -DLITTLE_ENDIAN -DWIN64 -DLITTLE_ENDIAN -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O2 -DNDEBUG -Wl,--strip-all -DNoRepository -ftemplate-depth-100 -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/finiteVolume/lnInclude -I../twoPhaseSystem/lnInclude -I../../phaseSystems/lnInclude -I../../interfacialModels/lnInclude -I../../interfacialCompositionModels/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/transportModels/compressible/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/thermophysicalModels/basic/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/thermophysicalModels/specie/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/thermophysicalModels/reactionThermo/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/transportModels/incompressible/transportModel -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/TurbulenceModels/compressible/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/TurbulenceModels/turbulenceModels/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/TurbulenceModels/phaseCompressible/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/combustionModels/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/fvOptions/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/meshTools/lnInclude @/home/ofuser/blueCFD/OpenFOAM-4.x/platforms/mingw_w64GccDPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels/includeHeaderPaths -IlnInclude -I. -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/OpenFOAM/lnInclude -I/home/ofuser/blueCFD/OpenFOAM-4.x/src/OSspecific/MSwindows/lnInclude -c derivedFvPatchFields/alphatFixedDmdtWallBoilingWallFunction/alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.C -o \?\C:\blueCFD\OpenFOAM-4.x\platforms\mingw_w64GccDPInt32Opt\applications\solvers\multiphase\reactingEulerFoam\reactingTwoPhaseEulerFoam\twoPhaseCompressibleTurbulenceModels\derivedFvPatchFields\alphatFixedDmdtWallBoilingWallFunction\alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.o
In file included from derivedFvPatchFields/alphatFixedDmdtWallBoilingWallFunction/alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.H:47:0,
from derivedFvPatchFields/alphatFixedDmdtWallBoilingWallFunction/alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.C:26:
lnInclude/alphatPhaseChangeJayatillekeWallFunctionFvPatchScalarField.H:1:137: fatal error: ../derivedFvPatchFields/alphatPhaseChangeJayatillekeWallFunction/alphatPhaseChangeJayatillekeWallFunctionFvPatchScalarField.H: No such file or directory
compilation terminated.
/home/ofuser/blueCFD/OpenFOAM-4.x/wmake/rules/General/transform:8: recipe for target '/home/ofuser/blueCFD/OpenFOAM-4.x/platforms/mingw_w64GccDPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels/derivedFvPatchFields/alphatFixedDmdtWallBoilingWallFunction/alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.o' failed
make[2]: *** [/home/ofuser/blueCFD/OpenFOAM-4.x/platforms/mingw_w64GccDPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels/derivedFvPatchFields/alphatFixedDmdtWallBoilingWallFunction/alphatFixedDmdtWallBoilingWallFunctionFvPatchScalarField.o] Error 1
/home/ofuser/blueCFD/OpenFOAM-4.x/wmake/makefiles/apps:39: recipe for target 'reactingEulerFoam' failed
make[1]: *** [reactingEulerFoam] Error 2
/home/ofuser/blueCFD/OpenFOAM-4.x/wmake/makefiles/apps:39: recipe for target 'multiphase' failed
make: *** [multiphase] Error 2"

[wyldckat]

Many thanks for the feedback!

Yes, part of the problem has to do with the long file-name paths. Although several measures were put into the wmake infrastructure for our port, it can still fail when re-building without first cleaning up the source code folders of the affected libraries/applications.

The detailed step-by-step instructions on how to build and do a git pull from our repositories is planned, but it will take us a few more weeks until we're able to get to it.

Nonetheless, from your description, I still need to know what was the exact command you used for building OpenFOAM, namely if you simply used:

./Allwmake

or:

./Allwmake -update

In the meantime, I'll also test this in a clean VM with Windows installed in it, to try and reproduce the same error and figure out the solution.

[wyldckat]

OK, I've finished testing and I've confirmed that the solution relies on a part of blueCFD-Core's installation that I haven't had the time to document yet.

Nonetheless, I'll give you a quick list of steps to follow to get things working:

1. First close all MSys/blueCFD-Core terminal windows that you have open.

2. Either use the Windows Start menu to access the apps section, then browse to blueCFD-Core 2016 and then click on the short-cut Extended Start Menu; or double-click on the short-cut on the Desktop named blueCFD-Core 2016 (Start Menu) and then in the short-cut Extended Start Menu on the new window.

3. From there, browse to Settings -> Local Drive Mode and double-click on Create Substitute Drive Letter X.

4. This will create a pseudo-virtual drive letter X: which acts as an alias path for the path you have, namely C:\blueCFD.

5. Use Windows Explorer to go to the path X:\ and then double-click on the short-cut blueCFD-Core_MSys2_mingw64, which will start the MSys terminal, based on this alias path.

6. Now run the following commands inside that terminal window:

   wclean all $FOAM_SOLVERS/multiphase/reactingEulerFoam
   ./Allwmake -k -j > log.make 2>&1
   

   The reason for the two options:
   -j build using all available cores, so that it builds faster.
   -k do not stop on the first error, because there will be some weird cases where it fails to build. This is documented in the release notes and will be addressed in issue Crazy hack and problems with building on Windows with MSys2 #2. I'll provide more details on how to solve these weird issues in the next comment.

[wyldckat]

The solution for building the applications that failed to build with the command from the previous comment, is to run the following commands:

foam
grep '\.exe] Error ' log.make | sed 's=.*/\(.*\)\.exe.*=\1=' | xargs -I {} find applications -name {} | while read line; do wclean $line; wmake $line; wmakeVerifyExeDependencies $line || wmake $line; done

This is assuming that the log file log.make has the output from the command used on the previous comment.

In a more explicit way, the previous command can also be coded like this:

grep '\.exe] Error ' log.make | \
    sed 's=.*/\(.*\)\.exe.*=\1=' | \
    xargs -I {} find applications -name {} | while read line
do
    wclean $line
    wmake $line
    wmakeVerifyExeDependencies $line || wmake $line
done

[NablaCFD]

Thank you for very quickly reply.

And I have finished testing your solution, it work well. Thank you very much.

I will continue to deeply play your release, and feedback your more information.

In addition, I also find another solution, I also completed the test and work well. now share with everyone.

"
Microsoft added a new feature to Windows 10 Insider Preview Build 14352 (This policy wasn't added until build 14352 of Win 10,and before 14352 it is not any affected) that resolves one of the longest
standing issues that users experienced when using Windows: the 260 character limit. By default, the maximum path length limit in Windows is 260 characters. (A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character.The limit of 260 characters led to all kinds of issues including the inability to run operations on files stored under paths exceeding the limit, issues with the extraction of files, and issues with transferring files from systems that have no such limit.Up until now all you could do was reduce the path to regain access to files, or use programs such as Long Path Fixer to resolve issues that you are experiencing.)

Starting with Windows 10 Insider Preview Build 14352, long paths beyond the normal 260 char limit per node can be enable to allow manifested win32 applications and Windows Store applications. Enabling this setting will cause the long paths to be accessible within the process.(note: The caveat here is the term "manifested win32 applications". While most win32 applications since the days of Windows Vista are manifested, it is usually the case that the applications need to declare capabilities explicitly. and Win32 is a set of APIs that are used to make what's commonly referred to as "desktop" programs. It has nothing to do with whether a program is inherently 32-bit or 64-bit.)

You must be signed in as an administrator to be able to enable or disable long paths.

1.Tap on the Windows-key(win+r), type gpedit.msc, and hit enter.
2.Confirm the UAC prompt (Local Group Policy Editor) if it appears.
3.Use the hierarchy on the left to navigate to the following policy: Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem > NTFS.
(In my computer's system, its now called "Enable Win32 long paths" under "Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem")
4.Locate the Enable NTFS long paths policy and double-click on it.
5.Switch its state to enabled.
6.Click ok.
"

Keep foaming
Qiang

[wyldckat]

Actually, MSys2 already provides most of the binaries with this ability, namely to handle long paths, without having to go around tweaking Windows to handle this issue.
The problem is that there are a few applications in the GCC/binutils stack that were not built with this feature and that is why we still have these problems in blueCFD-Core 2016.

Note: I've written a quick wiki page which consolidates most of this information: https://github.com/blueCFD/Core/wiki/Quick-notes-on-how-to-update-build