Forum_general

General

At this page you can post questions or start discussions on general topics related to Delft3D Flexible Mesh.

Please select a proper category below (if possible), to post your message or reply to an existing post. Please add tags to your posts to simplify searching.

 

** PLEASE TAG YOUR POST! **

 

 

 

 


Message Boards

RE: Different folder naming in Linux and Windows: cause of an error?

Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Definitions *
. dflowdm = version 1.1.113.34995
. Linux = 32-bit x86, Ubuntu 12.04 (home-compiled)
. Windows = 32-bit x86, Windows XP (pre-compiled)
. NetCDF = netcdf 4.2.1 and netcdf 4.2 (home-compiled)
NB I have compiled NetCDF and dflowfm with the same compiler.

Evidence
The runs in Windows are successful.
The runs in Linux (dflowfm <>.mdu --autostartstop) are broken by the error
'Could not put global attributes in NETCDF #139761720'
The last number seems to be always the same across different attempts.

Observation
Both in Linux and Windows I work with a model folder called 'Water Flow FM Model' (MODELROOT).
This name is set by Windows. I then copied and pasted the successful model folder into Linux and worked into it.
While dflowfm runs, I noted the following difference:
. Windows used to create a sub folder 'DFM_OUTPUT_water flow fm model'
. Linux creates a sub-folder 'DFM_OUTPUT_Water'.
Please note different string length and handling of upper cases and of spaces between words.

Did anyone come across this before?
In your opinion, can this disturb the path finding of the NetCDF files so that the program throws that error?
Any other thoughts based on this information are welcome.

Thanks for looking into this.

Giordano

* I have seen that:
. dflowfm 1.1.116 is now available but, as I click on the link anchor to download it, I still get the 1.1.113 tarball.
. netcdf is now 4.3.2 (but I stick to the settings of the Building on Linux guidelines for reproducibility)
. netcdf-fortran is now 4.4.1 (ditto)
JL
Joaquim Luis, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 9/21/13 Recent Posts
Sorry, you say that "dflowfm 1. 1.116 is now available".
Where is that? I don't find it anywhere.

Joaquim
Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Hi! As you probably know, dflowfm is not generally distributed yet and is only accessible to a restricted group of pilot users via https://publicwiki.deltares.nl/ (a website you may wish to browse anyway). If you are among those, the new release is given good prominence.
Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Additional information #1
The same situation also occurs with the latest releases of NetCDF (netcdf 4.3.2 and 4.4.1).
Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Additional information #2
The same runtime error is thrown with a dflowfm installation on Linux 64-bit too, namely
'Could not put global attributes in NETCDF #0'
Therefore this error does not seem to depend on the architecture, but it is caused downstream of the Linux compilation.

Compilation options (shell script)
DFLOWFM_MOUNT=/opt/dflowfm/dflowfm-1.1.113
EXPAT_MOUNT=/usr
METIS_MOUNT=/opt/metis/metis-5.1.0
NETCDF_MOUNT=/opt/netcdf/netcdf-4.2.1-4.2
PETSC_MOUNT=/opt/petsc/petsc-3.4.0

CPPFLAGS=-I$EXPAT_MOUNT/include FC=mpif90 F77=mpif90 \
NETCDF_FORTRAN_CFLAGS=-I${NETCDF_MOUNT}/include \
NETCDF_FORTRAN_LIBS="-L${NETCDF_MOUNT}/lib -lnetcdf -lnetcdff" \
PKG_CONFIG_PATH=${NETCDF_MOUNT}/lib/pkgconfig \
./configure --prefix=$DFLOWFM_MOUNT --with-mpi --disable-openmp --with-petsc=$PETSC_MOUNT --with-metis=$METIS_MOUNT

Program versions used
gcc 4.6.3
gfortran mpich2 4.6.3
g++ 4.6.3
autoconf 2.68
automake 1.11.3
flex 2.5.35
libexpat1, mpichlibexpat1-dev 2.0.1-7.2ubuntu1.1
mpich2 1.4.1-1ubuntu1
mpich 3.1.2 -- all tests passed
cmake 2.8.7
netcdf 4.2.1 -- all tests passed
netcdf-fortran 4.2 -- all tests passed
valgrind 1:3.7.0-0ubuntu3.1
petsc 3.4.0 -- all tests passed
metis 5.1.0
dflowfm 1.1.113

Any cue is welcome. Thanks for helping me out.
Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error?

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Additional information #3
The same situation occurs with dflowfm 1.1.116, the other conditions being equal.
Giordano Lipari, modified 5 Years ago.

RE: Different folder naming in Linux and Windows: cause of an error? (Answer)

Youngling Posts: 0 Join Date: 3/23/11 Recent Posts
Almost sorted: it does depend on the different handling of blank spaces in names between Windows and Linux!

At the end of a run with defaults, the directory tree in the project folder in Windows is
+ Water Flow FM Model
++ DFM_OUTPUT_water fm model
+ Water_Flow_FM_Model_output
++ DFM_OUTPUT_water flow fm model

While this goes smoothly in Windows, in Linux one rather gets
+ Water Flow FM Model
++ DFM_OUTPUT_water
++ flow
++ FM
++ model
arguably because in Linux the blank space in the default folder names should be 'escaped' or, even safer, substituted with _, as partly done. Then, dflowfm justly protests about not knowing where the NetCDF file to write into is.

All people who, unlike me, bothered to change the model name and thus, I presume, the folder naming may not have come across this flaw.

One workaround is to avoid the default assignment of the folder name by setting the variable OutputDir in the mdu file under the block [output]. Make sure you don't use blank spaces in your name (whether escaped or not), otherwise you bump again in the error message about reading out into the NetCDF file.

For those who use Delta Shell in Windows and then import the project folder in a Linux system (as I first did), the variable OutputDir can also be set through the GUI. Please double check whether the new setting goes into the mdu stored in the folder Water Flow FM Model or in the twin folder Water_Flow_FM_Model_output (I don't see this latter folder in Linux)

All's well that ends well. I stick to my last (ik blijf bij mijn leest, for the Dutch readers) and let the expert to assess the scope of this bug and the best remedy for it.