open TELEMAC-MASCARET The mathematically superior suite of solvers

Dear Chi-Tuan,

After thinking about this for a while longer I believe that with SPHERICAL COORDINATES = NO, the model is simply solved in standard cartesian coordinates without consideration of a geographical coordinate system (for instance setting up a numerical flume) - this makes sense, just the terminology of the keyword and user manual that makes it confusing (at least to me) and lead me to believe that spherical coordinates in the sense of latitude/longitude (opposed to cartesian projections) were being inferred.

With this in mind I have the following questions that perhaps you might be able to clarify and/or confirm for me please. Apologies for the lengthy post, but I think this would be good to clarify properly for future users also.

• With SPHERICAL COORDINATES = YES, the use has the option to either specify the SPATIAL PROJECTION TYPE as Lambert Cartesian (Opt 1), Mercator (Opt. 2) or Latitude/Longitude (Opt. 3). Can you confirm that this is the coordinate system of the input mesh? Most coastal domains I've modelled have been in UTM coordinates but with SPHERICAL COORDINATES turned off. If one wants to use a UTM projection with SPHERICAL COORDINATES = YES is this possible? I suppose that SPATIAL PROJECTION TYPE = 2 would work fine right? My only concern as discussed below is if the LATITU subroutine would work correctly with UTM in this case.


• If choosing SPATIAL PROJECTION TYPE = 3, the user has to supply the input mesh in the latitude/longitude coordinate system, although, the mesh is ultimately converted back to a mercator projection for computation with the origin of the mercator coordinate system computed with the LATITUDE/LONGITUDE OF ORIGIN POINT.


• If the user wishes to consider automatic and spatially variable CORIOLIS then SPHERICAL COORDINATES = YES must be specified. I assume that the latitude is computed from the specified LATITUDE OF ORIGIN POINT. Advice on the forums is that the LATITUDE/LONGITUDE OF ORIGIN POINT should be specified around the centre of the mesh but surely this would introduce some error, espectially over large domains. If using a UTM coordinate system, I assume that the proper approach would be to specify the origin of the UTM Zone, but I am not 100% confident that that the computation of LAT/LONG from UTM would be correct if there are differences between mercator and UTM (see first point). If the option was given to specify SPATIAL PROJECTION TYPE = UTM alongside the zone number then there shouldn't be any need to manually specify the origin point nor should there be if using SPATIAL PROJECTION TYPE = 3 for which the lat long is directly supplied by the input mesh as the code coulld be modified to automatically calculate this.


• If the user wishes to consider Astral Potential, TIDE GENERATING FORCE = YES must be specified. In Telemac2D, the user manual states that SPHERICAL COORDINATES = YES should be specified, but not in the T3D Manual. Again, I assume that the latitude longitude should be calculated in the same way as it is for the variable CORILOIS through the correct specification of LATITUDE/LONGITUDE OF ORIGIN POINT.


• It seems to me that GEOGRAPHIC SYSTEM is only used to provide information for the interpolation of the user supplied tidal databases to the mesh boundaries and does not in any way affect how the mesh coordinate systems are translated? There is an option here to supply UTM coordinates, but is this actually possible when using SPHERICAL COORDINATES = YES as there is no SPATIAL PROJECTION TYPE for UTM? (only Mercator)


• If the user wishes to use boundary conditions supplied from a tidal databse with OPTION FOR TIDAL BOUNDARY CONDITIONS = value other than 0 (e.g. TPXO), SPATIAL PROTECTION TYPE = 5 (e.g. mercator) has to be specified, otherwise it is automatically set by TELEMAC. In my initial example cases with SPHERICAL COORDINATES = YES, SPATIAL PROTECTION TYPE = 3 and GEOGRAPHIC SYSTEM = 1, I assume that this would lead to issues as my mesh coordinate system is suppled in lat/long whereas the interpolation algorithms are expecting a mercator protection. Similarly, if the mesh is supplied in UTM coordinates opposed to mercator, how does the TPXO interpolation algorirthm work when when SPATIAL PROTECTION TYPE = 5 is automatically set? I suspect that my issues with T3D have to do with something related to this. What I find interesting though is that in T2D, TPXO boundaries are correctly interpolated and work perfectly fine with SPHERICAL COORDINATES = YES, SPATIAL PROJECTION TYPE = 3 and GEOGRAPHIC SYSTEM = 1, even though it is stated in the log file that GEOGRAPHIC SYSTEM AUTOMATICALLY SET TO 5. Doesn't seem to work in T3D though - model runs but immediately does not converge, perhaps due to some strange boundary conditions that have been interpolated.

Hello Toby,

Sorry for the delay to answer but when you wrote the last posts of this topic, I was verby busy and forgot to answer after. Moreover, many things to check and to answer.

To start, a (short) reminder of a few concerned features.
It is a long time since the feature associated with SPHERICAL COORDINATES exists in TELEMAC-2D (v5p4 released around 2004 or before, I cannot check for before) and TELEMAC-3D (v6p3 released around 2013).
The keyword GEOGRAPHIC SYSTEM was introduced in v6p2 (2012) and is only used when interpolating tidal constituents from tidal database (e.g. TPXO, FES, NEA, JMJ) on nodes of the mesh (open boundaries nodes for boundary conditions or every node for initial conditions) because TELEMAC does not know the coordinates system used to generate the mesh. Currently GEOGRAPHIC SYSTEM is only used for tidal constituents interpolation and there is no link with SPHERICAL COORDINATES = YES at the moment.


First of all, I must admit the name of the keyword SPHERICAL COORDINATES is quite confusing and does not mean that the mesh is written in longitude/latitude.
It rather means that the equations are not solved in a "classical" way for a plane projection but takes into account that the Earth is not flat and that there are corrections to finally solve the equations for a plane projection (TELEMAC still needs to solve equations for a plane projection).
It is difficult to change the name of quite used keywords because the compatibility is needed for old steering files to be run for future versions. The exception is when a keyword is deleted.

Anyway, to answer some questions you have (and my preliminary answers may already help):
Your are right.
If SPHERICAL COORDINATES = NO, the equations are solved in the projection (x/y) provided by the mesh (or the transformed mesh if using e.g. USER_CORRXY subroutine) as expected.
To be investigated, but the automatic conversion is not available now for SPHERICAL COORDINATES = YES (see the call to INBIEF then LATITU from TELEMAC2D_INIT subroutine). The conversion is to be implemented (and the calls to the modifications at the right location are to be written) before being automatic for the user :)
Already done (if not using SPHERICAL COORDINATES = YES).
You are totally right.
Yes.
Currently no.
I would say no currently. There is no conversion from UTM to longitude/latitude for this feature at the moment. Mercator projection is currently expected if SPATIAL PROJECTION TYPE = 2.
Unfortunately, LATITU is only implemented for Mercator projection not UTM at the moment.
You are right.
You are right.
It may be, to be investigated.
Indeed as told before, UTM is not taken into account for SPHERICAL COORDINATES = YES at the moment.
To be investigated.
Yes.
You are right, it should be added for TELEMAC-3D (in the user manual + test in LECDON_TELEMAC3D as done in 2D).
I would say yes, but to be checked deeper. I am not sure if LATITUDE/LONGITUDE OF ORIGIN POINT would be used with UTM, to be investigated.
Yes, and every node of the mesh for initial conditions if using INITIAL CONDITIONS = TPXO SATELLITE ALTIMETRY.
Indeed, UTM is not taken into account for SPHERICAL COORDINATES = YES.
Yes if SPHERICAL COORDINATES = YES.
If setting SPHERICAL COORDINATES = YES, SPATIAL PROTECTION TYPE = 3, the coordinates are converted into Mercator projection (in READ_MESH_COORD called by ALMESH when allocating mesh, this one is called by POINT_TELEMAC2D/3D subroutine when allocating pointers for TELEMAC-2D/3D) before the step of interpolation of tidal constituents. To my point of view, there is no issue here.
Currently, using UTM projection with SPHERICAL COORDINATES = YES is not possible. With SPHERICAL COORDINATES = NO if using UTM projection, you have to set GEOGRAPHIC SYSTEM = 2 or 3 (depending if North or South) and the expected zone number with keyword ZONE NUMBER IN GEOGRAPHIC SYSTEM. No automatic set in this case.
As described before, it is not surprising that it works with the suggested setup of keywords in 2D for me.
Maybe you can share the whole files to investigate or at least a modified geometry file (coarser and/or modified or generic bathymetry) + every other input file to run and see your issue?
There is no example of TELEMAC-3D with SPHERICAL COORDINATES = YES in the database. There may be bug to be fixed. I do not have any operationnal material to test.

Before, can you try a few changes in INBIEF subroutine to initialise MES2D%XEL and MESH2D%YEL as done for 2D if PRESENT(MESH2D):
Addbeforein INBIEF subroutine.

Hope this helps,

Chi-Tuan

Hi,

Please Toby have a look at this fix I found for the global model:
www.opentelemac.org/index.php/kunena/21-...make-the-model-crash

After doing a research for MESH2D%X in the source code, I found where the problem was coming from.

The problem was in the FLUPRI (flux calculation) routine. The relative distances are calculated in MERCATOR.

A correction for the polar distortion (like done in LATITU routine) and the triangles crossing the +/-180 fixed everything.

I had instabilities propagating from the poles and from the IDL (international date line or the +/- 180° meridian)

I am using the latest version (v8p5r1) with both of the FORTRAN files in the user_fortran3D folder.

drive.google.com/drive/u/1/folders/18nHc...pfR2RnxQEmX6CwDdk6h_

I'll keep this drive active for a while.

I think this might also help people who had problems using TELEMAC3D close to polar latitudes.

Hi,

Great work on finding and fixing this.

In my case, I believe the issue may actually have been related to another bug which Alexander identified not long ago which was specifically related to using spherical coordinates with T3D. I believe you may have been part of the discussion on Gitlab.

I was recently working on a T3D model using spherical coordinates and had continual model instabilities from the first timestep. Changing to Mercator projection immediately solved the issue. My initial post was also related to T3D using spherical coordinates and I was unable to resolve it without changing to Mercator so was likely due to the same issue.

I am yet to test the model in spherical coordinates with the patched source code but am confident it will resolve the problem based on Alexander's description of the bug. Unfortunately I don't think the fix was pushed to V8P5.

Regards,
Toby