open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi Guys,

I am attemping to bring a T2D model over to T3D. The model is forced using TPXO boundaries and is in spherical coordinates. Model version is v8p3r0

I have noticed that in T3D that the initial values given by TPXO (TPXO SATELLITE ALTIMETRY = YES) are completely wrong giving me free surface values of around 40.

The setup of the model in terms of TPXO and coordinate system is exactly the same as T2D which works perfectly.

Has anybody run into this issue or aware of any bugs?

I am a little confused regarding the use of spherical coordinates. My mesh is in lat/long and I have used the following configuration for T2D up to this point without any TPXO issues:

---

SPHERICAL COORDINATES = YES
GEOGRAPHIC SYSTEM = 1 / WGS84 LAT LONG
SPATIAL PROJECTION TYPE = 3

LONGITUDE OF ORIGIN POINT = 38.59
LATITUDE OF ORIGIN POINT = 20.18

---

From what I understand using TPXO boundaries automatically sets the GEOGRAPHIC SYSTEM = 5 (mercator). Is the possible cause of this issue and if so why does T2D not have any issues?

So it seems the issue lies elsewhere - not TPXO. Will investigate further but am seeing some strange initial conditions on the first timestep.

Hello Toby,

I think your issue is the same as David Haverson, see:
www.opentelemac.org/index.php/kunena/21-...rdinates-output-file

You have a suggested fix for v8p3r0, but I would recommend you to upgrade your release to the latest one v8p3r1.

Hope this helps,

Chi-Tuan

Hi Chi-Tuan,

Thanks for the feedback. This was exactly the problem I was facing. I should have dug a little deeper on the forums. Good to know that it was a just a bug with the result printout. Was initially having issues with model stability which was making it a little difficult to track the source of the problem.

Cheers,

Hi Chi-Tuan,

I am having some strange issues with model stability working in the spherical coordinate system. I have only experienced this since moving from T2D over to T3D

I spent a few days playing with model parameters etc. to try and stabilise the numerics without success. In the end I decided to convert the model mesh to UTM coordinates and managed to get the model to run thinking I'd found the right setup. However, moving back to spherical coordinates to take advantage of automatic coriolis and astral forces, I am experiencing immediate non-convergence of the model.

While trying to debug the issue I have setup a relatively simple case model case forced only with TPXO tidal boundaries (544 boundaries with Thompson) with coriolis and astral forcing turned off. Have aslo turned off TPXO initial conditions setting constant values for both cases.

I am happy to attach the cas file for further investigation, but the important mesh related parameters for both cases are summarised below:

---

SPHERICAL COORDINATES

---

SPHERICAL COORDINATES = YES
GEOGRAPHIC SYSTEM = 1 / WGS84 LAT LONG
SPATIAL PROJECTION TYPE = 3

LONGITUDE OF ORIGIN POINT = 38.59
LATITUDE OF ORIGIN POINT = 20.18

RESULT FILE IN LONGITUDE-LATITUDE = YES

---

UTM COORDINATES

---

SPHERICAL COORDINATES = NO
GEOGRAPHIC SYSTEM = 2 / UTM
ZONE NUMBER IN GEOGRAPHIC SYSTEM =37

LONGITUDE OF ORIGIN POINT = 38.59
LATITUDE OF ORIGIN POINT = 20.18

RESULT FILE IN LONGITUDE-LATITUDE = NO

---

Are you able to see anything of immediate concern here that could point to where the issue lies? Unfortunately as the model is not converging at the first timestep its very difficult to understand what is happening.

Thanks,

Hello Toby,

When using UTM plane projection, the 3 keywords LONGITUDE OF ORIGIN POINT, LATITUDE OF ORIGIN POINT and RESULT FILE IN LONGITUDE-LATITUDE are useless.
Can you confirm that you get exactly the same resultats with or without giving a value in the steering file please?

For me, what is the most suspicious is the use of SPHERICAL COORDINATES = YES.

When using SPHERICAL COORDINATES = YES, and if at least one component of OPTION FOR TIDAL BOUNDARY CONDITIONS is not equal to 0, the keyword GEOGRAPHIC SYSTEM is automatically set to 5 (it is needed when interpolation TPXO solution on your mesh).

SPHERICAL COORDINATES = YES with SPATIAL PROJECTION TYPE = 3 may be sensitive to the values given to LONGITUDE OF ORIGIN POINT and LATITUDE OF ORIGIN POINT. I remember to have troubles once with TELEMAC-2D. You can try to change the values a little bit and see if your instabilities are damped or not.
One fix was to have good bathymetry to interpolate when doing the mesh and good care the mesh resolution in particular when bathymetry gradients may be big.

Perhaps you can try to convert your coordinates in longitude/latitude not in UTM but in Mercator? => SPHERICAL COORDINATES = YES + SPATIAL PROJECTION TYPE = 2
You can get the formulae to convert in BORD_TIDAL_BC subroutine ($HOMETEL/sources/telemac2d folder):
Hope this helps,

Chi-Tuan

Hi Chi-Tuan,

Thanks for the suggestions. I will take a look into these and get back to you with my findings.

I wanted to also highlight that I have used to separate model meshes for the 'spherical coordinate' and 'UTM' simulations. These were converted directly in BK.

To avoid potential time debugging the issue can you also please confirm whether TPXO boundaries should work using spherical meshes in T3D? I saw some older thread posts with users having difficulties with this configuration in T3D.

I just assumed that both T2D and T3D would use the same subroutines for conversion of coordinate systems, interpolation of TPXO etc but perhaps this is not the case. For instance Tidal potential forces require the spherical coordinate systems in T2D while this doesn't seem to be the case in T3D - its seem that some inconsitencies between the two models have occured over time.

Like I mentioned I had no issues whatsoever with exactly the same Spherical Coodinate connfiguration in my T2D model so I just find it a little strange. To make matters worse, the user manual is very confusing to me regarding the specification of the of the mesh coordidnate systems.

For instance, the use of spherical coordinates to me implies that the model grid is grid is given in spherical coordinates, so I am not sure why the option is then given to select a SPATIAL PROJECTION TYPE other than latitude/longitude even if the mesh is converted to mercator for computation. To be frank the current user documenation leaves a lot to be imagined for users not involved in the development.

Regards,
Toby

Hello Toby,

Can you send the "older thread posts with users having difficulties with this configuration in T3D" with tidal boundary conditions computed with TPXO solutions with SPHERICAL COORDINATES = YES?
For me, there used to be a problem when users set SPHERICAL COORDINATES = YES and GEOGRAPHIC SYSTEM not equal to 5 or 0. From v8p2, GEOGRAPHIC SYSTEM is automatically changed if not set correctly with SPHERICAL COORDINATES = YES (in August 2020 in the trunk or v8p2 since December 2020).

You are right, for the conversion of coordinate systems, TELEMAC-2D and TELEMAC-3D use the same subroutines.

Looking at the source code:
- with TELEMAC-2D, if you set TIDE GENERATING FORCE = YES, you have to use SPHERICAL COORDINATES = YES (and then automatically CORIOLIS = YES is set), this is done in lecdon_telemac2d.f,
- currently with TELEMAC-3D, there is no check in lecdon_telemac3d.F and if you do not set CORIOLIS = YES and SPHERICAL COORDINATES = YES, no tide generating force is computed (you can have a look at trisou.f).

I will see how the user manual can be improved for these features (SPHERICAL COORDINATES = YES in particular).

I try to be clear, let me know if it is not here:
The keyword SPHERICAL COORDINATES is disturbing, it does not mean the coordinates of the mesh are necessarily written in longitude/latitude but that the Shallow Water Equations are solved in Mercator projection.
Anyway, if using SPHERICAL COORDINATES = YES, you can generate your mesh directly in Mercator projection (then you have to set SPATIAL PROJECTION TYPE = 2) or in longitude/latitude (then set SPATIAL PROJECTION TYPE = 3) but TELEMAC (2D or 3D) cannot know how you have built your mesh if you do not set the keyword SPATIAL PROJECTION TYPE (it only knows you want to solve the equations in Mercator projection). In the 2nd case (= 3), TELEMAC converts longitude/latitude coordinates in Mercator projection so that it can solve the equations.

Hope this helps,

Chi-Tuan

Dear Chi-Tuan,

Haven't had a chance to go and test some of your suggestions but intend to get to it soon (hopefully this weekend).

In the meantime, the thread I was referring to is at the link here.

Thanks for the explanation regarding SPHERICAL COORDINATES, but I am still a little confused. My understanding is that at the end of the day the telemac equations are solved in cartesian coordinates (UTM, mercator, etc) regardless, so I'm not sure for what reason the keyword SPHERICAL COORDINATES is even required. Given that the user is also asked to provide the GEOGRAPHIC SYSTEM to define the input mesh coordinates with the option of either cartesian coordinates (mercator, utm etc) and WGS84 Lat/Long, its not clear to me what the SPHERICAL COORDINATES option is even doing. You mentioned that SPHERICAL COORDINATES means that the equations are solved in mercator projection, but what are they solved in if SPHERICAL COORDINATES = NO?

Am I mistaken by thinking that a simpler approach could be just to ask the user to provide the coordinate system of the input grid (e.g. LATLONG, UTM, Mercator) and have telemac perform the required coordinate system conversions automatically. If spatially variable coriolis, astronomical potential etc. is required, the model could convert the mesh coordinates to lat/long from whatever coordinate system is being used during initialisation - Obviously the correct coordinate system information would be necessary to provide to the model (e.g. UTM zone, or latitude/longitude of mercator origin etc).

Something similar could also be carried our for TPXO boundary conditions which I believe are provided to the model from the binary constituent files in Lat/Long.