path length issue for CSM about dssat-csm-os HOT 5 OPEN

Here is a hint as to what is going on. Firstly, it depends on the DSCSM047 binary location. Secondly this is what is happening when looking for files.

When DSSAT is installed on a short path (~/d/):

Could not find input file! 
  File was: //~/d/Genotype/WHCER047.ECO

On a long path (/blue/hoogenboom/share/apps/dssat47/4.7.5.12/):

Could not find input file! 
  File was: ///blue/hoogenboom/share/apps/dssat47/4.7.5.12/Genot/WHCER04

As you can see, it truncates both the directory and the filename. Hopefully this helps.

from dssat-csm-os.

Hi there!

I have bumped into DSSAT issues with long PATHs when I started to pack a DSSAT-related project (gym-DSSAT) with Spack. Spack installations usually result in really long paths. A real example, from my own system: /home/emilioj/spack/opt/spack/linux-debiann-skylake/gcc-11.3.0/dssat-pdi-0.2.4.7-bsobpuwizjrudu4ndpdtyn2lvdxo6b4e (114 chars, only the PATH!).

Apparently, the issue arises from the fact that 80-char strings are used in PATH.for functions (I do not know if there are more short allocations for string in other places of the code).

I have seen this open issue here, marked as 'high priority'. Do you know if there are plans to solve this in a near future?

Thanks in advance!
E

from dssat-csm-os.

Hi, @emilioj. I thought this issue had already been solved by @fabiooliveira72. Which version/branch are you using, and with which models are you facing issues? Is it with CSCER, CSCAS, CSYCA, or other models?

from dssat-csm-os.

Hi @emilioj and @lpmorenoc!

Yes, we are developing the increase of path lengths for dssat-csm-os. Unfortunately, this is a major issue in DSSAT and we need more time to pull request this issue. There are a lot of testing that need to be done in order to merge this code.

For right now the best way is to use 80 characters maximum for path length. Please try to reduce your paths or compile the project and move the executable to the /DSSAT48/... In this way, you can keep a short path for the executable. This will help you to keep working with DSSAT while finish to fix this issue.

Thank you. Please let us know if you need anything else.

Fabio Oliveira

from dssat-csm-os.

Hi @lpmorenoc and @fabiooliveira72!

Thanks for your feedback :-)

I tried both 4.7 & 4.8 versions with similar issues (and looking at PATH.for, the 80-char string limit seems hard-coded in both branches).

This is a snapshot using last commit in 'develop', id 05010ab, tagged as v4.8.1.0. I am running experiment UFGA8201.MZX, treatment 1. In the upper panes you can see the installation (make install) in a 'short' path and the corresponding execution. Everything works Ok.

Lower panes show the installation & execution when a longer path is used. I've used a path similar to what is required when using a Spack recipe [1] (actually, a real spack path would be even longer as it adds a hash depending on the specific build, such as '/home/emilioj/spack/opt/spack/linux-debiann-skylake/gcc-11.3.0/dssat-pdi-0.2.4.7-bsobpuwizjrudu4ndpdtyn2lvdxo6b4e').

I cannot reduce the Spack installation paths, but I think that creating a Spack environement view (a Spack facility to group packages and show them in a different path) can work as a workaround if I replace the long paths in DSSATPRO.L48 and run_dssat with the paths in the view.

Thanks again and I will be on alert about the fix in DSSAT :-)
E

[1] Spack https://spack.io https://github.com/spack/spack

from dssat-csm-os.