Earthdata Forum

I have installed the v7.5 branch from the OCSSW git repos manually as I did previously with v7.4 with the exception of bin3 which [ has been changed to opt ](https://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?tid=8640), and am seeing [pathing issues](https://github.com/USF-IMARS/imars_dags/issues/56).

When trying to use `modis_GEO.py` for instance, I get the following error:

```
-bash-4.2$ export OCSSWROOT=/opt/ocssw
-bash-4.2$ source /opt/ocssw/OCSSW_bash.env
-bash-4.2$ OUT_PATH=/srv/imars-objects/airflow_tmp/proc_myd01_to_myd0_otis_l2_gom_20180111T202000_geofile
-bash-4.2$ /opt/ocssw/run/scripts/modis_GEO.py --output=$OUT_PATH  /srv/imars-objects/airflow_tmp/A2018011.2020.hdf
Directory /opt/ocssw/var does not exist.
Using current working directory for storing the ancillary database file: ancillary_data.db
/opt/ocssw/run/bin/linux_64/geogen_modis: error while loading shared libraries: libdf.so.0: cannot open shared object file: No such file or directory
*** ERROR: geogen_modis failed to produce a geolocation file.
*** Validation test failed for geolocation file: proc_myd01_to_myd0_otis_l2_gom_20180111T202000_geofile
ERROR: MODIS geolocation processing failed.
```

Some notable information regarding this error:
* `/opt/ocssw/var` indeed does not exist, but `/ot/ocssw/run/var` does, and that is the path v7.4 was using previously.
* `libdf.so.0` doesn't exist, but I do have `/opt/ocssw/run/opt/linux_64/lib/libdf.so.0.0.0`

I put some quick symlinks in place to workaround these and just ran into more errors. I have little experience linking libraries though, so perhaps there is some easy fix.

As you have discovered, 7.5 OCSSW software uses a different directory structure, so manually installing into a 7.4-based structure would mean undoing the changes made for 7.5.  If there is a problem with the documented installation methods you might be better off sorting out those problems so you get the same directory tree others are using.

Unfortunately I am unable to install using the provided python install script because it is long-running and not idempotent.

I am attempting to install from git repositories as documented [here]( https://oceandata.sci.gsfc.nasa.gov/ocssw/ ), but the directory structure is not described. I requested documentation on this [previously]( https://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?tid=7742 ) for v7.4. I have attempted to figure this out again for v7.5 but am seeing these issues.

After looking through a sucessful install using the script as well as the content of the install script I see things have changed quite a bit. I will update here with the directory structure.

SeaDAS should not be installed using "root" privileges, and is limited to places where the installing user has write access.   A good way to see what the installer does is to set up a test user with minimal privileges and install the software for that user.

It is no longer-running than doing it manually....

The script knows where to put things and as you found, you can use it to look and see what it's doing.  It's not a complicated script. (OK, it got a little more complicated because we're still supporting the old directory structure, but it's still under a 1000 lines with a good bit of that being the input option parsing)

We provide the capability to do it manually, but there's a lot involved which is why we wrote the script - to save you the pain of doing it manually.
But if you insist, here's an example v7.5 directory structure with the MODIS-Aqua and MSI S2A and S2B data installed

$ ocssw
  |-ocssw-src
  |  |-src
  |  |-oel_util
  |  |-test
  |  |-cmake
  |  |-oel_hdf4
  |  |-include
  |-opt
  |  |-src
  |  |-lib
  |  |-include
  |  |-bin
  |  |-share
  |-var
  |  |-modis
  |  |-modisa
  |-scripts
  |  |-modules
  |-bin
  |-share
  |-common
  |  |-proj
  |  |-iop
  |  |-palette
  |-msi
  |  |  |-s2b
  |  |  |-s2a
  |-modis
  |  |-class
  |  |-pcf
  |  |-iop
  |  |-static
  |  |  |-aqua
  |  |-aerosol
  |  |-ocrvc

Thanks for your help. It seems I may need to rethink the way we have things set up here.

I had some trouble with the script previously and came into this 7.5 upgrade with a bias against it, but it does seem to be working well now.

As for installing as non-root: I agree and understand why, but some unrelated legacy quirks of our system mean that I will need to revisit that at a later date.