|
[Sponsors] |
[OpenFOAM.com] wmake deletes files and than stops |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 30, 2018, 10:37 |
wmake deletes files and than stops
|
#1 |
Senior Member
|
OpenFOAM-plus deletes dependency files upon errors, which later breaks the compilation:
Code:
tom@acticom19:~/OpenFOAM/OpenFOAM-plus/src/lagrangian/intermediate/parcels/derived/basicKinematicMPPICParcel> wmake wmake: 'Make' directory does not exist in /home/tom/OpenFOAM/OpenFOAM-plus/src/lagrangian/intermediate/parcels/derived/basicKinematicMPPICParcel Searching up directories tree for Make directory Making dependency list for source file makeBasicKinematicMPPICParcelSubmodels.C make: *** Deleting file '/home/tom/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/lagrangian/intermediate/parcels/derived/basicKinematicMPPICParcel/makeBasicKinematicMPPICParcelSubmodels.C.dep' Making dependency list for source file makeBasicReactingMultiphaseParcelSubmodels.C make: *** Deleting file '/home/tom/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/lagrangian/intermediate/parcels/derived/basicReactingMultiphaseParcel/makeBasicReactingMultiphaseParcelSubmodels.C.dep' make: *** No rule to make target '/home/tom/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/lagrangian/intermediate/parcels/derived/basicReactingMultiphaseParcel/makeBasicReactingMultiphaseParcelSubmodels.C.dep', needed by '/home/tom/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/lagrangian/intermediate/parcels/derived/basicReactingMultiphaseParcel/makeBasicReactingMultiphaseParcelSubmodels.o'. Stop. Regards, Tom |
|
January 31, 2018, 13:22 |
|
#2 |
Senior Member
|
Today I tried to use the v1712 source instead of the gitlab repository, so basically following these steps. Unfortunately the same happens.
I would like there to be some option that I can use to prevent the deletion of the erroneous .dep file, but from -help or -usage options to wmake I do not get a clue. I tried to compare the differences between wmake for -dev and -plus, but could not find where the different behavior is coming from. I would really like if someone has an idea. Regards, Tom |
|
February 2, 2018, 06:07 |
|
#3 |
Senior Member
|
Just an update:
I managed to fix this by copying the .dep files from our cluster to my computer. It worked for both v1712 sources and the git repository. Anyhow I think the reason I get corrupted .dep files is caused by some setting on my computer, but still if anyone has a clue on how I can prevent this deleting of the corrupted .dep files I would be very much interested. It still baffles me that the behavior is different between v1712/ESI and foundation versions. Regards, Tom |
|
March 18, 2018, 16:01 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Greetings Tom,
I'm somewhat fairly late to answer your questions, but here goes what I can answer, based on what I know:
Best regards, Bruno
__________________
Last edited by wyldckat; March 18, 2018 at 16:03. Reason: revised the text |
|
March 20, 2018, 05:06 |
|
#5 |
Senior Member
|
Dear Bruno,
Thanks for coming back on this. I am aware that there are differences between OpenCFD and foundation versions, but thank you for clearing things up. The warning about Make folder being present higher in the tree I have seen before indeed and does not worry me. The difference in locations may be why the files are deleted in the case of OpenCFD vs foundation. I think the reason the files need to be deleted are because of some system setting. The weird lines are just broken paths. It appears that if the files become larger than 64 Kb they are closed, which breaks some of the paths in the .dep files. Below is an example of this: Code:
tom@acticom19:~/OpenFOAM/OpenFOAM-dev> tail /home/tom/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/src/lagrangian/spray/parcels/derived/basicSprayParcel/makeBasicSprayParcelSubmodels.C.dep $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/NoComposition.H \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/NoComposition.C \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/SinglePhaseMixture.H \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/SinglePhaseMixture.C \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/makeReactingParcelPhaseChangeModels.H \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/NoPhaseChange.H \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/NoPhaseChange.C \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/LiquidEvaporation.H \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInclude/LiquidEvaporation.C \ $(WM_PROJECT_DIR)/src/lagrangian/intermediate/lnInctom@acticom19:~/OpenFOAM/OpenFOAM-dev> So I suspect the same thing happens on OpenCFD's version, but as it deletes the corrupted files the build stops, while on the foundation version I can manually delete the corrupted line, run ./Allmake again and it continues until the next error. It does not seem to cause any issue as everything eventually builds, but it would be better if the manual intervention would not be necessary. Hope this helps, Best Regards, Tom |
|
March 20, 2018, 16:44 |
|
#6 | |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Hi Tom,
I've re-read your posts... now I'm really intrigued. The symptoms do point to there being some setting that is restraining the generation of the ".dep" files... but my guesses so far are the following:
Best regards, Bruno |
||
March 21, 2018, 04:40 |
|
#7 |
Senior Member
|
Hi Bruno,
Thanks for coming back. The workstation is not using nfs or anything like that. I see a similar result with ulimit: Code:
tom@acticom19:~> ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 515310 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I am using OpenSUSE Leap 42.3. *edit: I just increased the max open files limit for dev and it seems to have fixed the issue there. I am not sure what would be the best solution to this in general, but probably this will work for me. Regards, Tom Last edited by tomf; March 21, 2018 at 06:05. Reason: Solution added |
|
April 15, 2018, 19:13 |
|
#8 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Quick note: At OpenCFD, they have made a recent change to their development code, which now should no longer have this requirement for wmkdep to have so many files opened. I believe it should be provided with their OpenFOAM v1806, in a few months.
|
|
October 31, 2018, 10:51 |
|
#10 |
Senior Member
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14 |
I seem to be experiencing a similar issue when trying to compile my own library with 1706 and 1712
wmake does this Code:
Making dependency list for source file FileName make: *** Deleting file `Make/linux64GccDPInt32Opt/path/to/FileName' I seem to be getting this only with the above-mentioned versions of OF. Both 1806 and more early versions compile with no problems, as well as the Foundation releases. Am I correct in my understanding that the error has nothing to do with my code, but some unlucky meddling with wmake has been done in the 1706 and 1712 releases? Here is the link to my library https://bitbucket.org/lesituu/libwal...s/src/develop/ |
|
November 3, 2018, 21:29 |
|
#11 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Greetings Timofey,
I'm a bit confused about what happened exactly... I've finished installing OpenFOAM-v1712 on CentOS 6.10 and then tried building the repository, you've pointed out with this version - branch "develop" to be specific - and I was not able to reproduce any error messages. When I run the command "ulimit -a" I get the following: Code:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 12888 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Best regards, Bruno |
|
November 4, 2018, 03:54 |
|
#12 |
Senior Member
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14 |
Hello Bruno!
Here is what I get Code:
core file size (blocks, -c) 1 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 128819 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) 28042432 open files (-n) 8192 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 128819 virtual memory (kbytes, -v) 26392880 file locks (-x) unlimited I should say that I'm compiling it on a cluster. There are many OF versions installed making it easy to test compilation. The downside is that I cannot change the ulimit. |
|
November 4, 2018, 07:46 |
|
#13 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Hi Timofey,
The limits are very generous and should not be the reason for the problems in this situation... So, that leaves us with the following possibilities:
Bruno |
|
November 9, 2018, 05:40 |
|
#14 |
Senior Member
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14 |
I could compile the same code for v1712 on a different cluster, so it's at least fairly certain this has to do with the OF setup and not with the code itself.
/Timofey |
|
November 11, 2018, 17:54 |
|
#15 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128 |
Quick answer: Without enough information to try and recreate the v1712 installation you have that is failing you, it's nearly impossible to reproduce the same issue to then try and figure out how to fix it
My best guess are the paths where you've placed your source code and OpenFOAM's source code. If there is a space, dot, plus, or any other non-alphabetical/numerical character, that could be enough to through things for a loop... The other possibility is that something else in the environment variables is contaminating the work-flow... the PATH variable comes to mind. |
|
November 12, 2018, 04:40 |
|
#16 | |
Senior Member
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14 |
Quote:
I'm pretty sure it is not the path o fmy code, I have the library in ... OpenFOAM/tmu-v1712/applications My bet would be on something being wrong with the install or configuration done by the cluster admins. My interest here is to be able to claim that the library compiles on 1712, which I think is pretty safe to do now. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|