gotm-model / code Goto Github PK

Hi,
I am trying to compile the manual. It looks like I need an executable or a script called "protex" (see Makefile in doc/).
I found this CTAN package https://ctan.org/tex-archive/web/protex which does not have any executable. Did I miss something?

side question: could it be possible to update the manual on http://gotm.net?

Thank you!

Good morning,

I am trying to compile an older version of GOTM, the v5.2, but I am not sure how to do it. I have tried following the steps written on the gotm.net webpage, but I keep getting the same error message when I try to run gotm_configure.sh:

-- Configuring incomplete, errors occurred!

See also "/fs/scratch/mare_exp/emilia/SCHISM/model/schism/src/GOTM5.2_andre/code/src/CMakeFiles/CMakeOutput.log".

But when I open the CMakeOutput.log file I don't see any error.

Can somebody help me or tell me where I can find another compilation guideline.
Thanks in advance

Hans and I have worked on support for plumes + adding a basal melt ice model to STIM.

The paper describing it is well under way but before publishing we would like to merge the changes to the GOTM code into master.

The overall changes to the code is not very big - but some key routines has been changed. I'll list those below - but first here are things that needed change:

1. specification of zeta - with 500m of ice on top of the water it is convenient to initialize zeta as Hice*rho_ice/rho_0
2. freshwater flux and {S,T}-flux always passed - they can come from air/sea or ice/water interface
3. basal melt is 'just' another STIM ice model. Updated API to do_ice() now also u* is passed.

Files of special interest:
salinity.F90, temperature.F90, analytical_profile.F90 and gotm.F90

Everything is in the plume branch. The gotm-cases have been updated with a plume folder. If anybody wants to try it out please contact me for an updated version of STIM (not yet commited).

Hi,
I don't know if this is a known problem, but I was unable to run the cmake step on Linux for Windows (WSL - ubuntu). It exited with:

CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find NetCDF (missing: NetCDF_INCLUDE_DIRS)
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  extern/flexout/cmake/Modules/FindNetCDF.cmake:80 (find_package_handle_standard_args)
  extern/flexout/CMakeLists.txt:39 (find_package)

I solved the problem by changing line 19 of GOTM\code\extern\flexout\cmake\Modules\ FindNetCDF.cmake to
set(NetCDF_INCLUDE_DIRS ${includedir} CACHE STRING "NetCDF include directories" FORCE)
without FORCE the variable was not being set.

Regards, Noel

Hi all,

I don't know if this is actually an "issue": GOTM is often used for multi-parameter runs. In this case, it is repeatedly called from some external software (Matlab, phyton, shell, ...) with slightly modified namelist parameters to cover a large parameter space step by step.

Perhaps we have this functionality already, and I just don't know? Perhaps it can be improved via the new yaml files?

Best, Lars

I am a new GOTM user, and I am hoping to use GOTM with the STIM submodule to investigate some details related to upper ocean evolution under sea ice. I have downloaded the most recent version of GOTM and installed it with STIM. In trying to look at ice-related processes, I am, however, running into some issues and what seem to be errors.

Given that I am new to using GOTM, it is likely that some of my issues may be due to user-error. To that end, I wonder if there are any example cases that I can run with the STIM submodule to confirm if I am able to reproduce the ice-module behaviour? (i.e., similar to the core GOTM example cases, but reproducing, e.g., the ice growth/melt shown here).

The density is relative straigh forward - but we should also investigate the use of the TEOS10 NN.

Clean up code and proper YAML-configuration

On gotm-devel we started a discussion on using TEOS-10 instead of the present density routines in GOTM - https://groups.google.com/u/1/g/gotm-devel/c/njWS8GBx0gw.

Based on experience the discussion becomes easier to follow if we use the 'Issues' feature of GitHub.

So that is why I've moved it here.

Hi,

I am planning to couple GOTM to MITgcm following the way it's done by PSOM
https://github.com/PSOM/V0.63/blob/master/code/model/src/couple_gotm.f90

I've noticed that they add an include and lib directories in their optfile
https://github.com/PSOM/V0.63/blob/master/code/optfile

But I couldn't find the lib directory in the build directory I compiled the current version of GOTM.
Only the modules directory.

My plan is to call do_turbulence inside MITgcm code at each timestep to update viscosity and diffusion coefficients using the setup from gotmturb.nml.

I would like to know what is the best way to do that.

A scenario simulation with GOTM could be done by choosing forcing from one or several years as a period to repeat several times, thereby creating a longer scenario period built upon actual forcing data. But if the repeat period is not 4 years long, the scenario simulation will run into a problem with leaps years.
Therefore, the option of GOTM being able to run on a calendar without leap years would enable to run scenario simulations build upon repeating actual forcing data much more smoothly.

I just tried to build gotm on my laptop (Mac, M3), but get the following error message, despite the fact that netcdf is installed and the library path seems correctly detected.

What am I missing? How do I fix this?

Error message:

[ 97%] Building Fortran object gotmlib/CMakeFiles/gotm.dir/gotm.F90.o
[ 98%] Building Fortran object gotmlib/CMakeFiles/gotm.dir/cmdline.F90.o
[100%] Building Fortran object gotmlib/CMakeFiles/gotm.dir/print_version.F90.o
[100%] Linking Fortran static library libgotm.a
[100%] Built target gotm
[100%] Building Fortran object CMakeFiles/gotm_exe.dir/src/gotm/main.F90.o
[100%] Linking Fortran executable gotm
ld: warning: ignoring duplicate libraries: '-lnetcdf'
ld: library 'netcdf' not found
collect2: error: ld returned 1 exit status
make[2]: *** [gotm] Error 1
make[1]: *** [CMakeFiles/gotm_exe.dir/all] Error 2
make: *** [all] Error 2

?2 gotmbuild_20240614b % grep netcdf *
CMakeCache.txt:NetCDF_INCLUDE_DIRS:PATH=/opt/homebrew/Cellar/netcdf-fortran/4.6.1/include
CMakeCache.txt:NetCDF_LIBRARIES:STRING=-L/opt/homebrew/Cellar/netcdf-fortran/4.6.1/lib -lnetcdff -lnetcdf -lnetcdf
CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_NetCDF:INTERNAL=[-L/opt/homebrew/Cellar/netcdf-fortran/4.6.1/lib -lnetcdff -lnetcdf -lnetcdf][/opt/homebrew/Cellar/netcdf-fortran/4.6.1/include][v()]

Details on netcdf as installed :

nf-config

This  4.6.1 has been built with the following features:

  --cc        -> clang
  --cflags    -> -I/opt/homebrew/Cellar/netcdf-fortran/4.6.1/include  -g -Wall -Wno-unused-variable -Wno-unused-parameter -O2

  --fc        -> /opt/homebrew/bin/gfortran
  --fflags    -> -I/opt/homebrew/Cellar/netcdf-fortran/4.6.1/include -I/opt/homebrew/Cellar/netcdf-fortran/4.6.1/include
  --flibs     -> -L/opt/homebrew/Cellar/netcdf-fortran/4.6.1/lib -lnetcdff -lnetcdf -lnetcdf
  --has-f90   -> TRUE
  --has-f03   -> yes

  --has-nc2   -> yes
  --has-nc4   -> yes

  --prefix    -> /opt/homebrew/Cellar/netcdf-fortran/4.6.1
  --includedir-> /opt/homebrew/Cellar/netcdf-fortran/4.6.1/include
  --version   ->  4.6.1

For depth-dependent variables, GOTM uses this peculiar format:

2017/02/18 00:00:00 155 3
-1.0 7.015652242915384 34.58407328910704
-2.0 7.020741135423573 34.58407194723329
-3.0 7.014843539086093 34.5840706053661

etc,

whereas EAT uses a standard TSV format:

2015-05-01 12:00:00	-15.	11.12	0.32

would it be possible to migrate GOTM to such a TSV format as well?

I'm currently trying to compile GOTM lake v5.3-673 under macOS (Catalina v10.15.3) after having no problems in compiling it under Ubuntu (18.04). I added the line -DGOTM_USE_STIM=on \ to gotm_configure.sh to include ice dynamics.

Now, running gotm_configure.sh works without problems and creates a gfortran directory, but gotm_build.sh reaches 100% and then fails in building the executable:

[100%] Linking Fortran executable gotm
Undefined symbols for architecture x86_64:
  "___netcdf_MOD_nf90_close", referenced from:
      ___netcdf_output_MOD_finalize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_create", referenced from:
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_def_dim", referenced from:
      _get_dim_id.4982 in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_def_var_manydims", referenced from:
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_enddef", referenced from:
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_get_att_text", referenced from:
      ___input_netcdf_MOD_check_restart_time in libinput_manager.a(input_netcdf.F90.o)
  "___netcdf_MOD_nf90_get_var_1d_eightbytereal", referenced from:
      ___input_netcdf_MOD_read_restart_data in libinput_manager.a(input_netcdf.F90.o)
  "___netcdf_MOD_nf90_get_var_eightbytereal", referenced from:
      ___input_netcdf_MOD_read_restart_data in libinput_manager.a(input_netcdf.F90.o)
  "___netcdf_MOD_nf90_inq_libvers", referenced from:
      _print_version_ in libgotm.a(print_version.F90.o)
  "___netcdf_MOD_nf90_inq_varid", referenced from:
      ___input_netcdf_MOD_read_restart_data in libinput_manager.a(input_netcdf.F90.o)
      ___input_netcdf_MOD_check_restart_time in libinput_manager.a(input_netcdf.F90.o)
  "___netcdf_MOD_nf90_open", referenced from:
      ___input_netcdf_MOD_read_restart_data in libinput_manager.a(input_netcdf.F90.o)
      ___input_netcdf_MOD_check_restart_time in libinput_manager.a(input_netcdf.F90.o)
  "___netcdf_MOD_nf90_put_att_one_eightbytereal", referenced from:
      ___netcdf_output_MOD_put_att_typed_real in liboutput_manager.a(netcdf_output.F90.o)
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_att_one_fourbyteint", referenced from:
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_att_one_fourbytereal", referenced from:
      ___netcdf_output_MOD_put_att_typed_real in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_att_text", referenced from:
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_var_1d_eightbytereal", referenced from:
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_var_2d_eightbytereal", referenced from:
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_var_3d_eightbytereal", referenced from:
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_put_var_eightbytereal", referenced from:
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_strerror", referenced from:
      ___input_netcdf_MOD_handle_err in libinput_manager.a(input_netcdf.F90.o)
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
      ___netcdf_output_MOD_finalize in liboutput_manager.a(netcdf_output.F90.o)
      _get_dim_id.4982 in liboutput_manager.a(netcdf_output.F90.o)
      ___netcdf_output_MOD_initialize in liboutput_manager.a(netcdf_output.F90.o)
  "___netcdf_MOD_nf90_sync", referenced from:
      ___netcdf_output_MOD_save in liboutput_manager.a(netcdf_output.F90.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [gotm] Error 1
make[1]: *** [CMakeFiles/gotm_exe.dir/all] Error 2
make: *** [all] Error 2

Any recommendations/ideas why it's failing during the last step? Both my systems (macOS and Ubuntu) are 64bit.

edit: It seems all errors are somehow related to netcdf. When running check_netcdf.sh, I get

robertladwig$ ./check_netcdf.sh 

Checking if CMake can find NetCDF compile and link information ...

-- Found NetCDF: -L/usr/local/Cellar/netcdf/4.7.3_1/lib  
CMake Error at extern/flexout/cmake/Modules/FindNetCDF.cmake:86 (add_library):
  add_library command is not scriptable


The above MUST include - Found NetCDF - to successfully continue

Thanks
Robert

When using GOTM with lake support version 5.4.0 , it is possible to set parameters so that GOTM will calculate lake level. The parameters are water_balance_method = 3 and zeta_method=3.
I guess these parameters are rarely used because many lakes have constant lake level. However, at least in lake Kinneret, calculating lake level is important. By calculating daily water balance out of the GOTM output file it can be shown that GOTM fails to calculate lake level correctly when using these parameters. If lake level is supplied to the model externally using parameters: water_balance_method = 2, zeta_method=2, GOTM calculates the water balance correctly using a residual stream.
Water balance calculation:
Daily water balance = Inflow + (evaporation + precipitation) * surface_area + Residual_stream – Δ_lake_level * surface_area.
Where the variables are from the GOTM output.nc file:
Inflow=Qlayer [m3/s] * 86400
Evaporation = evap [m/s] * 86400
Precipitation = percip [m/s] * 86400
surface_area = Af [m2]
Residual_stream = Qres [m3/s] * 86400
Δ_lake_level = number of layers * (h(t) - h(t-1)) [m/day].

(86400 is converting seconds into a day)
Daily water balance should be zero.
When calculating the water balance with parameters (water_balance_method = 2, zeta_method=2) the daily water balance is exactly zero when there is no change in lake level, and around zero when there is lake level change. This suggests that changes in lake volume is calculated different than Δ_lake_level * surface_area – maybe it is calculated hourly where I use the output file which is daily – resulting in a small difference. The daily balance is +/- 400 m3/day in my lake Kinneret model.
When calculating the water balance with parameters (water_balance_method = 3, zeta_method=3) the daily water balance is off by +/- 2*10^6 m3/day ! The water balance is obviously off with these parameters resulting in the inability to calculate lake level.
This issue can probably be reproduced with any lake model with these water balance parameters. Attached is an R code to calculate water balance, assuming output is daily.
Am I missing a parameter? Thanks

GOTM_water_balance.zip

Building only the turbulence library using cmake with -DGOTM_BUILD_LIBRARIES_ONLY=true fails in the v6.0.0 release (and the master branch as well) due to a missing dependency on input when building airsea. I don't think airsea is needed in the turbulence library, right? So moving the following line after the check on GOTM_BUILD_LIBRARIES_ONLY seems to fix this. I didn't check if this change breaks the building with FABM etc though... @bolding @jornbr

Hi, I would like to request - suggest an enhancement:
I'm using GOTM within QWET.
Currently, each run produces a "restart.nc" file. If you set in gotm.yaml, restart=true, than values in restart is used as initial conditions. However, the restart.nc file name is hardcoded and not a parameter. This means that every time you run the model with restart=true you get an initial conditions from the last run. I would like to suggest that the file name will be a parameter so you can set constant initial conditions. So I'm thinking of the restart.nc as a more accurate initial conditions (rather than the intended use - for restart). I find it important to set more detailed initial conditions for processes that take a years to stabilize, such as the humus sediment.
If the solution will include the ability of ParSAC to use it - this would be even better (currently parsac does not copy .nc files).

Shajar

I suggest adding topics such as turbulence, oceanography, ocean in the About section at https://github.com/gotm-model/code.

Hello,

this is a quick note to say that in the output file, z and zi are function of time, lat and lon. I don't know if this is the intended behavior. I seems to me that it should not since I read in gotm.F90

   call fm%register_dimension('lon',1,id=id_dim_lon)
   call fm%register_dimension('lat',1,id=id_dim_lat)
   call fm%register_dimension('z',nlev,id=id_dim_z)
   call fm%register_dimension('zi',nlev+1,id=id_dim_zi)
   call fm%register_dimension('time',id=id_dim_time)

and when I do
ncdump -h entrainment.nc

I see

        float z(time, z, lat, lon) ;
                z:units = "m" ;
                z:long_name = "depth (center)" ;
                z:standard_name = "??" ;
                z:path = "/column_structure" ;
                z:positive = "up" ;
                z:axis = "Z" ;
        float zi(time, zi, lat, lon) ;
                zi:units = "m" ;
                zi:long_name = "depth (interface)" ;
                zi:standard_name = "??" ;
                zi:path = "/column_structure" ;
                zi:positive = "up" ;
                zi:axis = "Z" ;

This is really a minor issue but in ncview my pointer does not show the correct depth: it shows a time instead.

Is there any chance this could be corrected?
It seems that this is handled by flexout so it might not be the best place to submit this issue?

Thank you

The example cases available for GOTM online usually include a section along the lines of

output:
   out:                                # path of output file, excluding extension
      time_unit: hour                       # time unit [second, hour, day, month, year, dt=model time step; default=day]
      time_step: 6                         # number of time units between output [min=1; default=1]
      time_method: point                   # treatment of time dimension [point=instantaneous, mean, integrated; default=point]
      variables:
      - source: *                          # variable name in model

This can be parsed by yaml.F90, but is AFAIK not actually valid YAML - * starts an alias. This becomes a problem when trying to parse the gotm.yaml files with tools outside GOTM, which usually rely on valid YAML.

I'm unsure where this issue belongs - is it GOTM, https://github.com/BoldingBruggeman/fortran-yaml/, or elsewhere? Or was there once a YAML version where * was a valid start for a plain scalar?

Old code should be found somewhere. Although we can efford high vertical resolutiion in GOTM, there may be in many applications issues with strong gradients moving to the fixed grid.

Remove all namelist based configuration except for turbulence and util (used by external 3D models - notably FVCOM). Maintaining the namelists configuration will be time consuming and error-prone and will not benefit the work done on GOTM being able to generate its own configuration. In addition we will remove many 100 lines of obsolete code. Included will also be the removal of all the .xml based code and files.

Hi,

I am getting error while compiling GOTM.
I thought that it would be related to the version, but in the documentation says that gfortran was tested for versions above 4.7.

Versions:

gcc (GCC) 4.8.1
GNU Fortran (GCC) 4.8.1
netCDF 4.3.0

-- The Fortran compiler identification is GNU 4.8.1
-- Check for working Fortran compiler: /share/pkg/gcc/4.8.1/bin/gfortran
-- Check for working Fortran compiler: /share/pkg/gcc/4.8.1/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /share/pkg/gcc/4.8.1/bin/gfortran supports Fortran 90
-- Checking whether /share/pkg/gcc/4.8.1/bin/gfortran supports Fortran 90 -- yes
-- Found NetCDF: -L/share/pkg/netcdf/4.3.0/lib -lnetcdff -lnetcdf -lnetcdf  
-- Configuring done
-- Generating done
-- Build files have been written to: /project/umd_amit_tandon/iury/research/models/GOTM/build

make[2]: Warning: File `extern/flexout/extern/yaml/CMakeFiles/yaml.dir/depend.make' has modification time 0.007 s in the future
make[3]: Warning: File `extern/flexout/extern/yaml/CMakeFiles/yaml.dir/depend.make' has modification time 0.0016 s in the future
make[3]: warning:  Clock skew detected.  Your build may be incomplete.
make[2]: warning:  Clock skew detected.  Your build may be incomplete.
make[2]: Warning: File `extern/flexout/extern/yaml/CMakeFiles/yaml.dir/yaml.F90.o.provides.build' has modification time 0.012 s in the future

/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:59.48:

      character(len=:), allocatable       :: key
                                                1
Error: Deferred-length character component 'key' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:220.39:

      character(:), allocatable :: text
                                       1
Error: Deferred-length character component 'text' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:155.44:

      character(:), allocatable :: long_name
                                            1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:59.48:

      character(len=:), allocatable       :: key
                                                1
Error: Deferred-length character component 'key' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
/project/umd_amit_tandon/iury/research/models/GOTM/code/extern/flexout/extern/fortran-yaml/yaml_settings.F90:36.50:

      character(len=:), allocatable   :: long_name
                                                  1
Error: Deferred-length character component 'long_name' at (1) is not yet supported
Fatal Error: Error count reached limit of 25.
make[2]: *** [extern/flexout/extern/yaml/CMakeFiles/yaml.dir/yaml_settings.F90.o] Error 1
make[1]: *** [extern/flexout/extern/yaml/CMakeFiles/yaml.dir/all] Error 2
make: *** [all] Error 2

I suggest adding the topic ocean in the About section, as explained at https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics

Hi, @bolding and @jornbr, since running GOTM with CVMix in the single column mode uses the non-local mixing, would it make sense to turn this on by default? I think gamh etc should be zero if CVMix is not used, right? Or is there a way to automatically turn this on when GOTM is built with CVMix?

Until now we have used the mean sea level as vertical reference in GOTM - which has been sufficient when doing ocean applications without massive amounts of ice on top.

Now two different use cases requires at least some thought.

Hans is working on melting under glacial ice where the ice thickness can be several 100 meters thick. One reference for the water/ice interface would be Hice*rho_ice/rho_0. For convenience it might still be useful to operate with a thickness of the water layer and have all calculations of e.g. temperature - like specification of two layer structure - or reading in profile data use this thickness as reference. The advantage is that making studies with the effect of ice thickness is easy as just one variable needs to be changed - Hice - and not have to change all depth values in the profile data file. But I don't know how these under ice observations are carried out in reality.

Another use case is with lakes - where it might still be possible to use the mean water level - even it is not well defined for some lakes. An alternative would be to use e.g. the z-coordinate of the deepest point in the lake relative to mean sea level (or geoid) - in this case z - the water level would be the total water depth.

In addition to the implications inside GOTM - it also have relevance when importing GOTM simulations into GIS - as a proper reference is mandatory.

Does anybody have ideas how we shall do this in a proper way to include all uses cases. As a side note - we are in the process of changing to TEOS-10. Here many subroutine calls use dbar (where a good proxy is depth) for pressure - but importantly minus the standard atmospheric pressure 101325 Pa. For a proper density calculation in alpine lakes there should actually be a correction - as we also use the surface pressure (and not mean sea level pressure) in air/sea flux calculations.

Here is a plot of the salinity of a sub-ice plume study - note the y-axis.

Comments are most welcome.

Hi

We (me and @nicogodet for Windows) have recently been trying to use gotm library on conda-forge.
GOTM can be built and coupled with TELEMAC, provided the *.mod files are found in the path.

Especially turbulence.mod, generated during make install and I am not sure this step has been done for packaging on conda-forge.

I have uploaded a simple conda-build recipe on my GitHub: https://github.com/tomsail/gotm-otm-feedstock, and this version works fine then when compiling with TELEMAC.

Is there any way to add turbulence.mod in the binaries of the official repository?

Thanks

PS: If you want me to make a reproducible version to traceback the error during TELEMAC compiling, I'll be happy to provide.