path length issue for CSM

[chporter]

Long pathnames fail in CSCER etc. code. When path to executable is long, model fails. See thread on private repo here: https://github.com/DSSAT/dssat-csm/issues/255

[frostbytten]

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.

[emilioj]

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

[lpmorenoc]

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?

[fabiooliveira72]

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

[emilioj]

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

[frostbytten]

Just boosting this issue. When working with DSSAT on HPC machines, it becomes really problematic. Using 4.8.2.1 and still run into the issue.

[fabiooliveira72]

Hi @frostbytten!

Yes, indeed. It is in my list to get this done and I am still trying to find time to work on this.

Thank you!

[lpmorenoc]

@frostbytten are you having this issue with all the models or just the CROPSIM legacy models (CSCER, CSCAS, CSYCA)? I know @fabiooliveira72 had a version of the model without that issue but it is outdated, @fabiooliveira72 do you want some help from me?

[fabiooliveira72]

Hi @lpmorenoc!

Yes, it is very outdated and when we move to this it will be merged into develop ASAP, because it is a major issue. Yes, I will need help to test it! I will let you know.

Thank you!

[pcboy]

@fabiooliveira72 Is there any news regarding this issue?

I was recently trying to create a nix package for DSSAT. But I'm encountering this exact issue.

It fails at loading files like CO2047.WDA, because the load path gets truncated.

I found that many PATH variables were indeed set as CHARACTER*80. If there is any news around this issue I'm very interested.

From what I see it's mostly:

• Changing all (or almost all) CHARACTER*80 to something like CHARACTER*255
• Changing all (or almost all) '(A80)' to '(A255)' in the corresponding READ()
• Make sure to also search for 92, which should likely be replaced by 255 + 12
• There are multiple piece of code like:

            IF (PATHL .LT. 80) THEN
               DO K = (PATHL+1),80

Where the 80 should also be replaced by 255.