Dear everyone,
I have fixed the problem in Spatial data projection. But now, I’m having another projection issue.
I am using UTM projection but when I run the simulation, I receive this error :
RuntimeError: Error while getting geographic coordinates of projected location
I have checked the projection requirement for UTM and it seems everything is right.
But I checked the json file, I found that the coordinate system for all the material is written in cartesian. Meanwhile, I have defined the coordinate system with geo-projected in my spatialdata base.
How can I fix this issue? I attached here the json file, pylith.cfg, and one spatial database file
projection issue_alvina.tar.gz (16.5 KB)
Thank you in advance.
Alvina K K
Dear Alvina,
Looking at your .json file, it appears that your mesh is a geoprojected UTM coordinate system, as you specified. The only places I see CSCart is in the output. That shouldn’t matter, as you don’t need to do a projection for your output. It still appears as though you are missing the necessary points in your .spatialdb file to constrain your slip distribution. One option would be to turn off linear interpolation for the slip, and see what sort of slip distribution you end up with. That might tell you where you are missing points.
Cheers,
Charles
Dear Charles @willic3 ,
I have turned of linear interpolation but it is still giving me the same error.
I have tried also to simplify the coordinate (2-3 digits after comma) in my coseismic spatial database and all the required original lon-lat coordinates in the spatial database. But it doesn’t work. I suspect that it is not because of the coseismic spatial database. Because I try to run the interseismic simulation and use slip-dependent for the creep slip (variation only along z. x and y = 0), it gives me the same issue. I have asked others who have done the same 3D subduction simulation but they use tmerc and geo-local-cartesian. While mine is in UTM.
I attached below all my files. Could you please help me to find the solution?
Dear Alvina,
Sorry for the delay – I was out of town for a few days. Looking at your files, it appears to me that your spatial database files are not in a geoprojected coordinate system, but are instead geographic coordinates (e.g., lon/lat/elevation). Assuming this is true, you will need to change all of your spatial database files so that the parameters are defining a geographic coordinate system (see Section C2.1.2 of the manual). Since it appears that your z-coordinate is in km, make sure you define your units accordingly. The definitions in your .cfg files should be fine, assuming you have properly defined your UTM geoprojected coordinate system (and that this is what was used when creating your mesh).
Cheers,
Charles
I noticed a couple of other things when looking at your spatial database files:
- In your coseismic slip file, you list both the data-dim and space-dim as 3. I am assuming that your slip values define the slip over the fault surface. In that case you would probably want a data-dim of 2 (values over a surface).
- I am unsure why you used a SimpleGridDB for your creep slip, since the only variation appears to be vertical. This shouldn’t affect the creep values, however.
Cheers,
Charles
Dear Charles @willic3 ,
Thank you for your kind reply. I attached the wrong coseismic slip database in the previous folder. But actually, I also have the coseismic slip database in lon-lat. I have tried with both (projected in x y z and original lon-lat) but all of them did not work.
I have fixed the unit for the depth (z) and the data-dim for all the spatial database but it still gives me some errors. For the coseismic simulation, I receive an unknown error (the detail of the error is not written). Meanwhile, the interseismic simulation still has the same projection error. For the creep slip spatial database, I am following the example. In the example, the variation is only along the depth but it uses SimpleGridDB. I have tried to change the creep spatial database into SimpleDB, I also adjust the creep input file setting in the cfg file (step03.cfg) into SimpleDB. But it gives me an error. Pylith can’t read the spatial database. But if I keep the cfg slip rate setting in SimpleGridDB (even though my spatial database is in SimpleDB), Pylith can pass this error.
I re-attached the file below.
Thank you for your assistance.
Alvina K K
Dear Alvina,
It still looks like the coordinates in your spatial database files are geographic (lon,lat,z); however, the parameters within your spatial database files are describing a geo-projected coordinate system (x,y,z). You will need to provide parameters appropriate for a geographic coordinate system. The coordinates and parameters within your current spatial database files are inconsistent with each other. If you look at the manual chapter I referred to earlier you will see an example of a geographic coordinate system. It is much simpler than a geo-projected system since no projection is being performed. The parameters within your spatial database files should look something like:
cs-data = geographic {
// Conversion factor to get to meters (only applies to vertical
// coordinate unless you are using a geocentric coordinate system). to-meters = 1.0e+3
space-dim = 3 // 2 or 3 dimensions
// Run ‘‘proj -le’’ to see a list of available reference ellipsoids. // Comments are not allowed at the end of the next line.
ellipsoid = WGS84
// Run ‘‘proj -ld’’ to see a list of available datums. // Comments are not allowed at the end of the next line.
datum-horiz = WGS84
// ‘‘ellipsoid’’ or ‘‘mean sea level’’
// Comments are not allowed at the end of the next line.
datum-vert = ellipsoid
// Use a geocentric coordinate system?
is-geocentric = false // true or false
}
Important: There are significant limitations in using a SimpleDB spatial database with geographic coordinates. A SimpleDB computes distances using sqrt(x2+y2+z**2), so the distance is distorted if the coordinates are longitude, latitude, and elevation. This can lead to a variety of errors. As a result, we strongly recommend using a geographic projection if you want to use a SimpleDB.
SimpleGridDB spatial databases are different because we interpolate along each coordinate axis independently, so a geographic coordinate system will work fine.
Based on Brad’s comments, it is probably best to convert your coordinates using Proj (you can use the cs2cs command). You can just create a file of your coordinates by taking the first 3 columns of your spatial database (convert your z-coordinate to meters first), then run it through cs2cs with the appropriate parameters. In your spatial database files you have additional origin-lon and origin-lat parameters. If this is what you used to create your mesh, you will then need to subtract the corresponding Cartesian coordinates from your computed coordinates. I am confused about your mesh coordinate system. Is it regular UTM, or is it shifted?
Cheers,
Charles
Dear Charles and Brad,
I missunderstood this part " Looking at your files, it appears to me that your spatial database files are not in a geoprojected coordinate system, but are instead geographic coordinates (e.g., lon/lat/elevation)."
So this is my coseismic spatialdatabase in utm projection :
fault_slabtop_coseismic_utm47s.spatialdb.tar.gz (5.5 KB)
I have tried to use the projected spatialdatabase above and I am still having the same issue for both interseismic and coseismic simulation (my creep spatialdatabase has no variation along x and y. Only z dependent. But I have the same issue).
I try to recreate the geometry using merc projection and adjust all the spatialdatabase in merc projection and my interseismic simulation can pass the projection issue. Eventhough I receive new error :
[0]PETSC ERROR: KSPSolve has not converged due to Nan or Inf norm
step03-parameters.json.tar.gz (13.9 KB)
So to create the mesh and convert the coordinate, I use qgis rather than proj. Because I am not familiar using proj and the slab contour script provided in the examples. I am using UTM projection zone 47S for the UTM projection.
Regards,
Alvina K K
Hi Alvina,
I haven’t looked at things in detail, but in looking at your new spatial database, it appears that your (x,y) coordinates are in m, while your z coordinates are in km. They should all use the same units, and you need to use the corresponding to-meters value in your parameters. Also, you are still using origin-lon and origin-lat, now both set to zero, which I suspect is causing some strange behavior. I would delete both of those values.
Cheers,
Charles
Dear Charles,
Thank you for your fast response.
I have changed the depth in meter, adjust “to-meters” into meter, and delete the original lon-lat part. But the same error still exists.
fault_slabtop_coseismic_utm47s.spatialdb.tar.gz (5.5 KB)
Regards,
Alvina KK
Dear Alvina,
Looking at your most recent spatial database, it appears as though many of the points in your spatial database lie below the fault surface, which could be a problem (see attached figures), plus they do not surround your fault surface. I would think that nearest neighbor interpolation should work, though. To do linear interpolation, I think you would want to project your coordinates to the fault surface, and provide a set of values that surround the fault (they would probably be set to zero slip).
Cheers,
Charles
Dear Charles,
I have tried to use nearest neighbor interpolation but the projection issue still exists. Eventhough, for example, there is a problem with the coseismic slip database with the fault mesh geometry, the projection issue will only exist for the coseismic simulation. Meanwhile, I try the interseismic simulation without the variation along x and y axis, I still have the same projection issue. But when I use the mesh geometry in mercator projection and adjust all the spatialdatabase in mercator, Pylith can pass the projection issue as written here Error while getting geographic coordinates of projected location - #10 by alvinakkuncoro.
Regards,
Alvina KK
I suggest taking a couple steps back to get to the bottom of these issues with the coseismic slip.
- Use a UniformDB. Make sure the simulation runs without errors and produces the correct results.
- Use a SimpleDB with a single point matching the values in the UniformDB. The results should be exactly the same as 1. First use the same coordinate system as the mesh and then use the desired coordinate system.
- Use a SimpleDB with two points (data-dim=1) that span the depth of the fault with the same slip values as the UniformDB. The results should be exactly the same as 1 and 2. First use the same coordinate system as the mesh and then use the desired coordinate system.
- Use a SimpleDB or SimpleGridDM with the topology that you want (line or planar surface) with the same slip values at all points that matches the UniformDB. The results should still be the same as 1, 2, and 3. First use the same coordinate system as the mesh and then use the desired coordinate system.
- Finally, add in the spatial variation in slip that you want by adjusting only the slip values, keeping the coordinates the same.
You may also want to create a very small toy test case with a box (similar to examples/3d/hex8) to experiment with using georefenced coordinate systems. Make the smallest test case (static problem, small mesh, single fault) possible. This makes debugging much easier.
Dear Brad,
I am sorry for the slow response.
I just tried using UniformDB but still got the same projection issue. But it is working if I use mesh geometry in Mercator projection and all the spatialdatabase+cfg files assigned to Mercator projection as well.
I will try to look at your suggestion to do a small test referred to examples/3d/hex8.
Thank you in advance.
Alvina K K
What is the “projection issue” you have when you are using a UniformDB? There are no coordinate transformations being done when using a UniformDB.
Dear Brad,
I am also feeling weird since I used UniformDB. This is the error :
RuntimeError: Error while getting geographic coordinates of projected location.
Regards,
Alvina K K
What is the entire output from the simulation? Please capture all output to a log file and include it.
Please find here the error report,
projection error.log.tar.gz (1.7 KB)
Thank you.
Best Regards,
Alvina KK
