Welcome,
Guest
|
|
TOPIC: TPXO Boundaries not working in T3D
TPXO Boundaries not working in T3D 2 years 1 month ago #41143
|
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.
|
The administrator has disabled public write access.
|
TPXO Boundaries not working in T3D 2 years 2 weeks ago #41503
|
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): My understanding is that at the end of the day the telemac equations are solved in cartesian coordinates (UTM, mercator, etc) regardless Your are right.You mentioned that SPHERICAL COORDINATES means that the equations are solved in mercator projection, but what are they solved in if SPHERICAL COORDINATES = NO? 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.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 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 :)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. Already done (if not using SPHERICAL COORDINATES = YES).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. You are totally right.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? Yes.If one wants to use a UTM projection with SPHERICAL COORDINATES = YES is this possible? Currently no.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? 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.My only concern as discussed below is if the LATITU subroutine would work correctly with UTM in this case. Unfortunately, LATITU is only implemented for Mercator projection not UTM at the moment.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. You are right.If the user wishes to consider automatic and spatially variable CORIOLIS then SPHERICAL COORDINATES = YES must be specified. You are right.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. It may be, to be investigated.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). Indeed as told before, UTM is not taken into account for SPHERICAL COORDINATES = YES at the moment.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. To be investigated.If the user wishes to consider Astral Potential, TIDE GENERATING FORCE = YES must be specified. Yes.but not in the T3D Manual. You are right, it should be added for TELEMAC-3D (in the user manual + test in LECDON_TELEMAC3D as done in 2D).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. 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.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 Yes, and every node of the mesh for initial conditions if using INITIAL CONDITIONS = TPXO SATELLITE ALTIMETRY.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) Indeed, UTM is not taken into account for SPHERICAL COORDINATES = YES.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. Yes if SPHERICAL COORDINATES = YES.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. 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.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? 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.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. As described before, it is not surprising that it works with the suggested setup of keywords in 2D for me.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. 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): Add IF(PRESENT(MESH2D)) THEN
CALL OV('X=C ', X=MESH2D%XEL%R, C=0.D0, DIM1=NELEM)
CALL OV('X=C ', X=MESH2D%YEL%R, C=0.D0, DIM1=NELEM)
ENDIF IF(SPHERI) THEN
!
IF(PRESENT(MESH2D)) THEN
CALL LONGITU(MESH2D%XEL%R,MESH%COSLAT%R,MESH2D%IKLE%I,
& NELMAX2,NELEM2) Hope this helps, Chi-Tuan |
The administrator has disabled public write access.
|
TPXO Boundaries not working in T3D 3 months 3 weeks ago #45307
|
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. |
The administrator has disabled public write access.
The following user(s) said Thank You: ah_sl
|
TPXO Boundaries not working in T3D 3 months 6 days ago #45402
|
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 |
The administrator has disabled public write access.
|
|
Moderators: pham