[CIG-SHORT] Spherical 3d gravity initial stress
Demian Gomez
demiang at gmail.com
Wed Nov 9 10:11:50 PST 2016
Brad,
Using the SimpleGridDB with a geographic (lon,lat,dep) coordinate system
seems to have worked fine. Thanks very much. Even though the spatialdb
files are large (1e6 points) Pylith loads them in a few seconds.
The last question I have is: The stress field in the db should be expressed
in the coordinate system of the db, right? In other words, stress_xx =
stress_yy = stress_zz = rho*g*depth and stress_xy = stress_yz = stress_xz =
0 and Pylith will transform this into stress_xx, stress_yy, stress_zz,
stress_xy, stress_yz and stress_xz in the ECEF coordinate system, where
stress_xy, stress_yz and stress_xz are not equal to zero. Or should I write
the stress field in the ECEF coord sys?
Demián
--
*Dr. Demián D. Gómez*
Postdoctoral Researcher
The Ohio State University - School of Earth Sciences
275 Mendenhall Laboratory
125 South Oval Mall
Columbus, Ohio 43210
Cell: +1 (901) 900-7324
email: gomez.124 at osu.edu
On Wed, Nov 9, 2016 at 12:20 PM, Brad Aagaard <baagaard at usgs.gov> wrote:
> On 11/09/2016 09:13 AM, Demian Gomez wrote:
>
>> I didn't realize that there had to be one data point at each
>> intersection of the grid. I was only leaving the points that I actually
>> need to make the file smaller. Is it possible to use a transformation so
>> that I can specify the points in lat lon depth and let Pylith transform
>> them into X,Y,Z (ECEF)? Say, something like is-geocentric = false?
>>
>
> It *is* possible to use geographic coordinates with a SimpleGridDB because
> it searches each coordinate independently to locate the points in the grid.
>
> With a SimpleDB the algorithm assumes the points are located arbitrarily
> within the data dimension. To find nearby points it computes distances, so
> the spatial database needs to use a Cartesian coordinate.
>
> Brad
>
>
>
>> Thanks for your help,
>>
>> Demián
>>
>> --
>> *Dr. Demián D. Gómez*
>> Postdoctoral Researcher
>> The Ohio State University - School of Earth Sciences
>> 275 Mendenhall Laboratory
>> 125 South Oval Mall
>> Columbus, Ohio 43210
>> Cell: +1 (901) 900-7324
>> email: gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>>
>>
>> On Wed, Nov 9, 2016 at 12:04 PM, Brad Aagaard <baagaard at usgs.gov
>> <mailto:baagaard at usgs.gov>> wrote:
>>
>> Demian,
>>
>> Your header shows the grid is
>> num-x = 33
>> num-y = 21
>> num-z = 28
>>
>> so the total number of points should be 33*21*28, but I only see 592
>> points in the file.
>>
>> Brad
>>
>>
>> On 11/09/2016 08:55 AM, Demian Gomez wrote:
>>
>> Brad,
>>
>> I'm analyzing the far-field (> 800 km from a thrust fault)
>> co-seismic
>> displacements and the effect of the asthenospheric stiffness in
>> the lithospheric stress guide. It's mostly a "theory" analysis
>> and I
>> cannot neglect the effect of sphericity since this would be highly
>> criticized by reviewers.
>>
>> I am trying to implement a spatial grid db as you suggested, but
>> I am
>> having a few problems. First for all, for some reason Pylith is
>> crashing
>> with my spatial grid with the following error:
>>
>> RuntimeError: Error occurred while reading spatial database file
>> 'spatialdb/initial_stress-layer1.spatialdb'
>> I/O error while reading SimpleGridDB data.
>>
>> I thought the problem could be the size of the spatialdb so I
>> reduced
>> the number of
>> points but the problem persisted.
>>
>> I then downloaded a traction db example from a benchmark
>> (https://github.com/geodynamics/pylith_benchmarks/tree/
>> master/dynamic/scecdynrup/tpv102
>> <https://github.com/geodynamics/pylith_benchmarks/tree/
>> master/dynamic/scecdynrup/tpv102>
>> <https://github.com/geodynamics/pylith_benchmarks/tree/
>> master/dynamic/scecdynrup/tpv102
>> <https://github.com/geodynamics/pylith_benchmarks/tree/
>> master/dynamic/scecdynrup/tpv102>>)
>> to compare it against my file. I couldn't see any remarkable
>> differences
>> (except the coordinate system, number of points, etc) so I used my
>> header (modifying num-x, num-y and num-z) with the data portion
>> of the
>> benchmark spatial db. Even though the number of values (columns)
>> in this
>> spatial db do not agree with the 6 stress components that I need
>> (the
>> benchmark uses 7 values) and the values itself are completely
>> meaningless in terms of stress, Pylith does now pass the material
>> initialization. It then crashes with the second layer where I
>> left the
>> spatial db unmodified.
>>
>> There seems to be some kind of problem with my data portion of the
>> spatial db, but I can't find it. I looked for CRLF/LF problems,
>> field
>> sizes, etc just in case, but found no differences. Attached you
>> will
>> find the spatial grid db that crashes Pylith. I'd appreciate if
>> you
>> could take a look at it to see if there is anything obviously
>> wrong.
>>
>> Demián
>>
>> --
>> *Dr. Demián D. Gómez*
>> Postdoctoral Researcher
>> The Ohio State University - School of Earth Sciences
>> 275 Mendenhall Laboratory
>> 125 South Oval Mall
>> Columbus, Ohio 43210
>> Cell: +1 (901) 900-7324 <tel:%2B1%20%28901%29%20900-7324>
>> <tel:%2B1%20%28901%29%20900-7324>
>> email: gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>>
>>
>>
>> On Wed, Nov 9, 2016 at 9:50 AM, Brad Aagaard <baagaard at usgs.gov
>> <mailto:baagaard at usgs.gov>
>> <mailto:baagaard at usgs.gov <mailto:baagaard at usgs.gov>>> wrote:
>>
>> Demian,
>>
>> The code for initializing the initial stress and strain
>> fields is in
>> the method ElasticMaterial::_initializeInitialStress() in
>> libsrc/pylith/materials/ElasticMaterial.cc.
>>
>> Before you head in that direction, I would seriously
>> consider the
>> size of the approximation in using a flat domain compared to a
>> spherical domain relative to the other assumptions in your
>> problem.
>> In other words, do your have sufficient resolution in all
>> of your
>> other parameters that you know you need to use a domain with a
>> spherical cap?
>>
>> Regards,
>> Brad
>>
>>
>>
>> On 11/08/2016 04:08 PM, Demian Gomez wrote:
>>
>> Hi Brad,
>>
>> Thanks for your answer.
>>
>> Would it be possible to modify Pylith's code to
>> calculate the
>> initial
>> tractions during runtime without having to specify them
>> through a
>> spatial database? I can try to do it if you can provide
>> me with some
>> orientation on where I should start looking. It seems
>> that for a
>> model
>> constructed in ECEF coordinates, calculating stress_xx,
>> stress_yy and
>> stress_zz should be trivial if I have access to the cell
>> centroids and
>> the material density.
>>
>> Thanks again,
>> Demián
>>
>> --
>> *Dr. Demián D. Gómez*
>> Postdoctoral Researcher
>> The Ohio State University - School of Earth Sciences
>> 275 Mendenhall Laboratory
>> 125 South Oval Mall
>> Columbus, Ohio 43210
>> Cell: +1 (901) 900-7324
>> <tel:%2B1%20%28901%29%20900-7324> <tel:%2B1%20%28901%29%20900-73
>> 24>
>> <tel:%2B1%20%28901%29%20900-7324>
>> email: gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>>>
>>
>>
>>
>> On Mon, Nov 7, 2016 at 12:42 PM, Brad Aagaard
>> <baagaard at usgs.gov <mailto:baagaard at usgs.gov>
>> <mailto:baagaard at usgs.gov <mailto:baagaard at usgs.gov>>
>> <mailto:baagaard at usgs.gov <mailto:baagaard at usgs.gov>
>> <mailto:baagaard at usgs.gov <mailto:baagaard at usgs.gov>>>> wrote:
>>
>> Demian,
>>
>> I think you can get things to work with a 1-D spatial
>> database with
>> some minor changes.
>>
>> WARNING: This will only work if stress_xx = stress_yy
>> =
>> stress_zz
>> and stress_xy = stress_yz = stress_xz = 0. This is
>> due to
>> the fact
>> that the orientation of the gravity vector is
>> different in the
>> projected coordinate system than it is in the
>> geocentric
>> coordinate
>> system.
>>
>> You should construct your model in a geocentric
>> local Cartesian
>> coordinate system. This is a geocentric coordinate
>> system
>> with the
>> origin at the surface.
>>
>> The initial tractions should be in a projected
>> (flat) geographic
>> coordinate system, so that stress(z) = integral of
>> rho*g
>> from 0 to z.
>>
>> As an aside, the SimpleGridDB provides much faster
>> interpolation
>> than SimpleDB for a logically Cartesian grid because
>> it can
>> find the
>> relevant points without a global search. The points
>> need to
>> conform
>> to a grid, but the x, y, and z coordinates do not
>> have to be
>> spaced
>> uniformly.
>>
>> Regards,
>> Brad
>>
>>
>>
>> On 11/06/2016 01:16 PM, Demian Gomez wrote:
>>
>> Dear all,
>>
>> I am trying to turn on gravity in a quasi-static
>> problem
>> that
>> uses a 3D
>> spherical cap model with layers (see attached
>> figure for
>> geometry and
>> displacement field without gravity). The
>> coordinate
>> system of
>> the mesh
>> is ECEF and in pylithapp.cfg I've defined
>> coordsys =
>> spatialdata.geocoords.CSGeo. My spatial
>> databases for
>> material
>> properties, etc are defined using:
>>
>> num-locs = 1
>> data-dim = 0
>> space-dim = 3
>> cs-data = geographic {
>> to-meters = 1.0
>> space-dim = 3
>> ellipsoid = sphere
>> datum-vert = ellipsoid
>> is-geocentric = true
>> } // cs-data
>>
>> Since the layers are uniform, I use
>> db_properties.query_type =
>> nearest.
>>
>> To turn on gravity, I need to set the initial
>> lithostatic stress =
>> g*rho*h for each element (I can't use a uniform
>> database
>> anymore), but
>> because this is a large model (~15e6 elements),
>> the
>> sizes of the
>> initial
>> stress databases are > 300 MB which makes Pylith
>> take a very
>> long time
>> to initialize the materials (so far I've waited
>> almost
>> 12 hours and
>> Pylith was still initializing the first layer!).
>>
>> Following this thread:
>>
>>
>> http://lists.geodynamics.org/pipermail/cig-short/2014-July/0
>> 01818.html
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html>
>>
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html>>
>>
>>
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html>
>>
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html
>> <http://lists.geodynamics.org/pipermail/cig-short/2014-July/
>> 001818.html>>>
>>
>> I have now attempted to create an initial stress
>> spatial
>> database that
>> is only 1D as follows:
>>
>> #SPATIAL.ascii 1
>> SimpleDB {
>> num-values = 6
>> value-names = stress-xx stress-yy stress-zz
>> stress-xy
>> stress-yz stress-xz
>> value-units = Pa Pa Pa Pa Pa Pa // units
>> num-locs = 2
>> data-dim = 1
>> space-dim = 3
>> cs-data = geo-local-cartesian {
>> origin-lon = -72.6425
>> origin-lat = -35.6331
>> origin-elev = 0
>> to-meters = 1.0
>> ellipsoid = sphere
>> datum-vert = ellipsoid
>> } // cs-data
>> }
>> 0.0000 0.0000 0.0000
>> 0.000
>> 0.000
>> 0.000 0.00 0.00 0.00
>> 0.0000 0.0000 -104911.1753
>> -2674950661.887
>> -2674950661 <tel:2674950661> <tel:2674950661
>> <tel:2674950661>>.887
>> -2674950661 <tel:2674950661> <tel:2674950661
>> <tel:2674950661>> <tel:2674950661 <tel:2674950661>
>>
>> <tel:2674950661 <tel:2674950661>>>.887 0.00 0.00 0.00
>>
>>
>>
>> and setting db_initial_stress.query_type = linear.
>>
>> My idea was that Pylith would map the
>> geo-local-cartesian from the
>> spatial database to ECEF coordinates in
>> geocoords.CSGeo.
>> However, I got
>> the following error during execution:
>>
>> mpinemesis: spatialdb/SimpleDBQuery.cc:352: void
>>
>>
>> spatialdata::spatialdb::SimpleDBQuery::_findLinePt(std::
>> vector<spatialdata::spatialdb::SimpleDBQuery::WtStruct>*):
>> Assertion `locIndexA >= 0' failed.
>>
>> My questions are:
>>
>> 1) Is it possible to mix coordinate systems the
>> way I did?
>> 2) Is there another way to tell Pylith that the
>> initial
>> stresses
>> in my
>> model vary linearly with depth, even when I have
>> an ECEF
>> coordinate
>> system? I would like to avoid having to assign the
>> initial stress to
>> every element one by one (which leads to a very
>> long
>> initialization time).
>>
>> Any suggestions will be greatly appreciated. Let
>> me know
>> if you need
>> more information.
>>
>> Cheers,
>> Demián
>>
>> --
>> *Dr. Demián D. Gómez*
>> Postdoctoral Researcher
>> The Ohio State University - School of Earth
>> Sciences
>> 275 Mendenhall Laboratory
>> 125 South Oval Mall
>> Columbus, Ohio 43210
>> Cell: +1 (901) 900-7324
>> <tel:%2B1%20%28901%29%20900-7324>
>> <tel:%2B1%20%28901%29%20900-7324>
>> <tel:%2B1%20%28901%29%20900-7324>
>> email: gomez.124 at osu.edu
>> <mailto:gomez.124 at osu.edu> <mailto:gomez.124 at osu.edu
>> <mailto:gomez.124 at osu.edu>>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>>>
>> <mailto:gomez.124 at osu.edu
>> <mailto:gomez.124 at osu.edu> <mailto:gomez.124 at osu.edu
>> <mailto:gomez.124 at osu.edu>>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>
>> <mailto:gomez.124 at osu.edu <mailto:gomez.124 at osu.edu>>>>
>>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>>
>>
>>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>
>>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>>
>>
>>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>
>>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>>
>>
>>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>
>>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org <mailto:CIG-SHORT at geodynamics.org>
>> <mailto:CIG-SHORT at geodynamics.org
>> <mailto:CIG-SHORT at geodynamics.org>>
>>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >>
>>
>>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org <mailto:CIG-SHORT at geodynamics.org>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org <mailto:CIG-SHORT at geodynamics.org>
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short>
>>
>>
>>
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>>
>>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/cig-short/attachments/20161109/4b3e1d7e/attachment-0001.html>
More information about the CIG-SHORT
mailing list