CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Installation

[OpenFOAM.com] wmake deletes files and than stops

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By tomf
  • 1 Post By tomf

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 30, 2018, 10:37
Default wmake deletes files and than stops
  #1
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
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.
Unfortunately this makes that I cannot compile the latest version anymore. For both OpenFOAM-5.x and -dev I always have some weird last line at some point in the .dep files during compilation. I have to manually delete that line and than it compiles. But plus deletes the .dep file alltogether. I hope there is a way to prevent this from happening?

Regards,
Tom
tomf is offline   Reply With Quote

Old   January 31, 2018, 13:22
Default
  #2
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
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
tomf is offline   Reply With Quote

Old   February 2, 2018, 06:07
Default
  #3
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
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
tomf is offline   Reply With Quote

Old   March 18, 2018, 16:01
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Greetings Tom,

I'm somewhat fairly late to answer your questions, but here goes what I can answer, based on what I know:
  1. The folder "src/lagrangian/intermediate/parcels/derived/basicKinematicMPPICParcel" does not have the sub-folder "Make". That sub-folder is actually located at "src/lagrangian/Make", that is why wmake gives the first complaint.
  2. The developments made at OpenCFD do not always include all of the developments for the version made available by the OpenFOAM Foundation.
  3. Once of the key differences in how the two projects deal with the intermediate files is as follows:
    1. The intermediate files on the versions by the OpenFOAM Foundation are kept in the same "platforms/$WM_OPTIONS" folder, within the respective sub-folders for "src" and "applications". This makes it easier when it's necessary to nuke a complete build associated to a "$WM_OPTIONS".
      • In case you don't know, try running the following command, to see what I'm referring to when I write "$WM_OPTIONS":
        Code:
        echo $WM_OPTIONS
    2. Those files on the versions by OpenCFD, will place the files at "build/$WM_OPTIONS", which makes it easier to nuke just the intermediate files.
  4. If my suspicion is correct, in either projects, the "dep" files will likely be deleted if the paths defined within those "dep" files do not match the current paths. For example, if you cloned the whole build from "/opt" at the cluster into your own home folder, that would explain why the "dep" files are being purged, as part of the maintenance steps within wmake's work-flow.
  5. As for what you wrote here:
    Quote:
    Originally Posted by tomf View Post
    For both OpenFOAM-5.x and -dev I always have some weird last line at some point in the .dep files during compilation. I have to manually delete that line and than it compiles.
    Only by seeing the weird line, I might be able to diagnose what happened exactly.
Either way, I would need to have more details on how you proceeded with building OpenFOAM in your workstation, in order to try and reproduce the same errors. Because I've done a quick test with OpenFOAM 5.x and it didn't give me those errors (although I didn't change the source code files either ).


Best regards,
Bruno
__________________

Last edited by wyldckat; March 18, 2018 at 16:03. Reason: revised the text
wyldckat is offline   Reply With Quote

Old   March 20, 2018, 05:06
Default
  #5
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
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>
As these files usually contain the $(WM_PROJECT_DIR) variable it works by copying the .dep files from other computers into the correct location and build everything again.

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
tomf is offline   Reply With Quote

Old   March 20, 2018, 16:44
Default
  #6
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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:
  1. If your home folder is not allocated locally and instead it's retrieved via NFS or something similar, then it might explain why the file is capped at exactly 64kB.
  2. Another possibility is the limit on the number of files open, which should be a matter of checking with the following command:
    Code:
    ulimit -a
    • It has been known to happen that the wmkdep utility that OpenFOAM uses for generating the ".dep" files will easily hit the maximum files open limit that is commonly imposed on Linux. For example, my Ubuntu 16.04 installation gives the following limits:
      Code:
      core file size          (blocks, -c) 0
      data seg size           (kbytes, -d) unlimited
      scheduling priority             (-e) 0
      file size               (blocks, -f) unlimited
      pending signals                 (-i) 120163
      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) 120163
      virtual memory          (kbytes, -v) unlimited
      file locks                      (-x) unlimited
    • If I cross-reference with the number of lines in the file you mentioned... here is the commands I used to gather all of the longest ".dep" files:
      Code:
      foam
      find platforms/$WM_OPTIONS -name "*.dep" | xargs wc -l | sort -g
      And I've gotten the following with a recent build of OpenFOAM-dev:
      Code:
           977 platforms/linux64GccDPInt64Opt/src/lagrangian/intermediate/parcels/derived/basicReactingParcel/makeBasicReactingParcelSubmodels.C.dep
           990 platforms/linux64GccDPInt64Opt/src/lagrangian/intermediate/parcels/derived/basicKinematicMPPICParcel/makeBasicKinematicMPPICParcelSubmodels.C.dep
          1005 platforms/linux64GccDPInt64Opt/src/lagrangian/intermediate/parcels/derived/basicReactingMultiphaseParcel/makeBasicReactingMultiphaseParcelSubmodels.C.dep
          1015 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/reactingParcelFoam/simpleReactingParcelFoam/simpleReactingParcelFoam.C.dep
          1016 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/sprayFoam/sprayFoam.C.dep
          1021 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/sprayFoam/engineFoam/engineFoam.C.dep
          1024 platforms/linux64GccDPInt64Opt/applications/solvers/combustion/fireFoam/fireFoam.C.dep
          1024 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/coalChemistryFoam/coalChemistryFoam.C.dep
          1024 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/reactingParcelFoam/reactingParcelFoam.C.dep
          1024 platforms/linux64GccDPInt64Opt/applications/solvers/lagrangian/sprayFoam/sprayDyMFoam/sprayDyMFoam.C.dep
          1024 platforms/linux64GccDPInt64Opt/src/lagrangian/spray/parcels/derived/basicSprayParcel/makeBasicSprayParcelSubmodels.C.dep
    • Funny enough that this is something that I was made aware of only due to the community ports of OpenFOAM for Mac OS X and Windows, where this limit is usually hit a lot harder (wmkdep would complain it could not open more files). A bit of googling and you can find one such example here: https://github.com/mrklein/openfoam-os-x/wiki
      Quote:
      Increase maximum number of open files (necessary for creation of certain lnInclude folders)
      Code:
       ulimit -n 8912
    • After increasing the limit on my Ubuntu machine, I have gotten a few more lines:
      Code:
      1039 platforms/linux64GccDPInt64Opt/src/lagrangian/spray/parcels/derived/basicSprayParcel/makeBasicSprayParcelSubmodels.C.dep
    • The weird part is that your file ends at line 1003... so it's possible that wmkdep crashed in your run, which would explain why the file had been stopped being written at the 64kB mark, namely when it was last flushed to disk.
Any chance you can state which Linux Distribution you are using?


Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   March 21, 2018, 04:40
Default
  #7
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
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
From this list I would also suspect the max locked memory of 64 kbytes, but I can not change that as a user.

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
wyldckat likes this.

Last edited by tomf; March 21, 2018 at 06:05. Reason: Solution added
tomf is offline   Reply With Quote

Old   April 15, 2018, 19:13
Default
  #8
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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.
wyldckat is offline   Reply With Quote

Old   May 2, 2018, 06:24
Default
  #9
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 634
Rep Power: 32
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi all,

This commit seems to have fixed the issue for me for dev.

Regards,
Tom
wyldckat likes this.
tomf is offline   Reply With Quote

Old   October 31, 2018, 10:51
Default
  #10
Senior Member
 
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14
tiam is on a distinguished road
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'
to every file and then exists with a "no rule to make target..." error.


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/
tiam is offline   Reply With Quote

Old   November 3, 2018, 21:29
Default
  #11
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
What do you get?

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   November 4, 2018, 03:54
Default
  #12
Senior Member
 
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14
tiam is on a distinguished road
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.
tiam is offline   Reply With Quote

Old   November 4, 2018, 07:46
Default
  #13
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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:
  1. Perhaps with the version v1712 doesn't have any issues, but when you tested it, perhaps there may have been a shell environment contamination from using v1706 in the same terminal?
  2. Perhaps the path to your custom source code was not supported in v1706 and v1712?
  3. Perhaps something went wrong with the installation in the cluster? Possibly some environment variable was not properly defined?
    • For diagnosing this, I would suggest getting the output from the export command for each shell environment with the respective OpenFOAM environment.
  4. Perhaps the real problem is revealed only if you show us the complete build output? Having only a couple of lines with a vague error message could be the reason why it's not possible to pinpoint the issue.
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   November 9, 2018, 05:40
Default
  #14
Senior Member
 
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14
tiam is on a distinguished road
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
tiam is offline   Reply With Quote

Old   November 11, 2018, 17:54
Default
  #15
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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.
wyldckat is offline   Reply With Quote

Old   November 12, 2018, 04:40
Default
  #16
Senior Member
 
Timofey Mukha
Join Date: Mar 2012
Location: Stockholm, Sweden
Posts: 118
Rep Power: 14
tiam is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
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.



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.
tiam is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 22:35.