[CIG-SHORT] Question about accuracy in Pylith
Demian Gomez
demiang at gmail.com
Tue Oct 18 09:53:12 PDT 2016
Hi Charles,
Thanks again for your helpful comments. I replaced the "cleanup volume"
with the remesh command, and things have improved now. To begin with, the
remesh process does not yield tets with lower quality, which is something I
was experiencing when using cleanup. There are, however, some elements that
won't improve. The reason seems to be that the nodes that compose these
elements lie on a surface and the remesh command does not move those nodes
unless you specify the FREE keyword in the remesh command. The problem is
that when I specify FREE, Trelis (16.1) crashes... I'll contact CSIMSOFT to
let them know.
I've been also playing with the bias factor by gradually reducing it from
1.05 (as in the example) down to 1.02. This also helped a lot. The stress
concentrations are now much, much smaller and the plots look much cleaner.
Did you guys do any experiments regarding the change in element size, or do
you know if there is any ideal value for the bias factor? Is there a reason
for a value of 1.05 in the meshing example? This may be a problem to
problem issue, but I'm wondering if there is any rule of thumb as there is
for the condition number.
Thank you for your time,
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 Sun, Oct 16, 2016 at 5:34 PM, Charles Williams <willic3 at gmail.com> wrote:
> Hi Demian,
>
> Mesh generation is the most difficult part of modeling. There are a few
> additional commands that sometimes help. Here’s one example:
>
> remesh tet quality condition no greater than 2.0 inflate 2
>
> What the remesh command does (you can look it up in the Trelis
> documentation) is find the elements with quality worse than the specified
> threshold, and remeshes them. The inflate argument determines how large a
> region is remeshed. Another option is the cleanup command:
>
> cleanup volume all
>
> This command deletes the existing mesh and replaces it with a more
> optimized mesh.
>
> You will have to experiment a bit to see what might work best. Note that
> sometimes either of these commands can result in a dramatic increase in the
> number of elements. Good luck, and let me know if this helps.
>
> Cheers,
> Charles
>
>
>
> On 17/10/2016, at 9:56 AM, Demian Gomez <demiang at gmail.com> wrote:
>
> Hi Charles,
>
> Thanks for your help. I've been using an analytic function to have a
> graded tetmesh (as in the example in the meshing directory). I also tried
> smoothing the mesh using the iterative approach in the examples:
>
> ${condnum=2.0}
> ${loop(4)}
> volume all smooth scheme condition number beta {condnum} cpu 2
> smooth volume all
> ${condnum=condnum-0.1}
> ${endloop}
>
> I've noticed that while the smoothing reduces the number of elements with
> distorted shapes, it also tends to make a few of them worse. For example, I
> start with a mesh where the maximum condition number is, say, 4. I apply
> smoothing and after the process is over, the maximum condition number is
> now 7. It seems that this problem occurs near the intersection of the fault
> plane and each of the layers of my model (see figure; meshed surfaces are
> the fault interface). Since the fault dip angle is ~ 18 degrees, I have a
> sort of wedge where the elements tend to have larger condition numbers.
>
> I already tried to refine the mesh around the curve where the fault plane
> intersects the surface and the layer and then apply smoothing, but that
> didn't help much. I did multiple experiments and, at these locations, I
> can't make the condition number < ~3 no matter what I do.
>
> I also obtained a stress profile and the mesh quality on that same
> profile, as suggested by Brad. The mesh condition number is actually very
> decent at the location of the profile (never exceeds 1.5), but the stress
> shows lots of kinks (see attached plots; no axis labels, sorry, but X is
> distance from some reference in the Paraview profile and Y either stress or
> quality). I also checked that the condition number is < 2 around the
> location where I take the profiles. Therefore, I am assuming that the high
> condition numbers at the fault are distorting my results everywhere.
>
> Do you have any suggestions on how can I solve this problem? It seems that
> I must be doing something wrong since I haven't seen anybody with this type
> of problems.
>
> Thanks,
> Demián
>
> PS: Regarding Tabrez' comment, my solution is always converging.
>
> --
> *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 Fri, Oct 14, 2016 at 4:18 PM, Charles Williams <willic3 at gmail.com>
> wrote:
>
>> Hi Demian,
>>
>> Ideally, you would like all condition numbers to be less than 2.0. Also,
>> the gradients in cell size may also influence your solution. It might be
>> worthwhile to make use of sizing functions to provide a more nicely graded
>> mesh. There are several examples in the meshing directory.
>>
>> Cheers,
>> Charles
>>
>>
>> > On 15/10/2016, at 8:05 AM, Brad Aagaard <baagaard at usgs.gov> wrote:
>> >
>> > Demian,
>> >
>> > For a quasi-static problem the global accuracy of the solution should
>> not be controlled by the worse cells. You should aim for a condition number
>> of about 2.0 or less. I strongly recommend using ParaView to see if there
>> is a correlation between condition number (or aspect ratio) and the local
>> fluctuations in stress/strain that you see. If there is a correlation, this
>> should tell you what condition number to aim for.
>> >
>> > Regards,
>> > Brad
>> >
>> >
>> > On 10/14/2016 11:58 AM, Demian Gomez wrote:
>> >> Hi Brad,
>> >>
>> >> Thanks. Here's the output for the mesh quality:
>> >>
>> >> Tet quality, 3297540 elements:
>> >>
>> >> Condition No. ranges from 1.000e+00 to 4.650e+00 (3297540 entities)
>> >>
>> >> Red ranges from 4.128e+00 to 4.650e+00 (3 entities)
>> >>
>> >> Magenta ranges from 3.607e+00 to 4.128e+00 (69 entities)
>> >>
>> >> DkYellow ranges from 3.086e+00 to 3.607e+00 (196 entities)
>> >>
>> >> Yellow ranges from 2.564e+00 to 3.086e+00 (862 entities)
>> >>
>> >> Green ranges from 2.043e+00 to 2.564e+00 (4427 entities)
>> >>
>> >> Cyan ranges from 1.521e+00 to 2.043e+00 (75597 entities)
>> >>
>> >> Blue ranges from 1.000e+00 to 1.521e+00 (3216386 entities)
>> >>
>> >>
>> >> The highest Co. number is 4.65 and there are only 3 elements, mostly on
>> >> the edges. Can this distort all the solution? Also, although we want
>> all
>> >> the elements to be as close to 1 as possible, is there an acceptable
>> >> range limit?
>> >>
>> >>
>> >> Thank you,
>> >>
>> >> 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 Fri, Oct 14, 2016 at 2:28 PM, Brad Aagaard <baagaard at usgs.gov
>> >> <mailto:baagaard at usgs.gov>> wrote:
>> >>
>> >> Demian,
>> >>
>> >> Have you looked at mesh quality (aspect and condition numbers close
>> >> to 1.0)? Distorted cells (slivers, squashed tets, etc) will be
>> >> stiffer and may cause local stress/strain concentrations. My guess
>> >> is that your 2-D mesh has better quality. Look to see if there is a
>> >> correlation between condition number or aspect ratio and the kinks,
>> >> etc in your stress field (you can do this in ParaView). If so, then
>> >> spend some time playing with the bias value, cell size, and
>> >> smoothing to improve the mesh quality.
>> >>
>> >> Regards,
>> >> Brad
>> >>
>> >>
>> >>
>> >> On 10/14/2016 11:17 AM, Demian Gomez wrote:
>> >>
>> >> Dear Brad, Matt and Charles,
>> >>
>> >> I have a question regarding the accuracy of the solution using
>> >> tets. I
>> >> have a model with a biased tet mesh (4 km at the fault and 160
>> >> km at the
>> >> edges, ~2200 km away) from which I am trying to get the strain
>> and
>> >> stress on some depth profiles at ~ 400 km from the fault. I am
>> >> running
>> >> Pylith with the refiner on (only one level) to refine my mesh
>> and
>> >> improve the resolution.
>> >>
>> >> The problem I'm having is that when I plot the strains and
>> >> stresses, the
>> >> plots are very "noisy" (see profiles_70.png). The displacement
>> >> looks ok,
>> >> maybe a few bumps and kinks here and there, but acceptable. I
>> think
>> >> these small displacement kinks are translating into the "noise"
>> and
>> >> larger kinks in strain and stress. I did tests in 2D (on a cross
>> >> section
>> >> of my 3D model) to figure out the best discretization size, and
>> >> if I use
>> >> a mesh with constant element size (say, 1 km), then everything
>> >> is smooth
>> >> and nice (see profiles_70_2D.png). However, a 3D model of the
>> >> size that
>> >> I need meshed with 1 km elements is huge and very impractical.
>> >> Moreover,
>> >> there shouldn't be any problems with using a biased mesh since
>> >> there are
>> >> examples within Pylith were you guys use this type of mesh.
>> >>
>> >> I know that I can improve the accuracy by using hexes, but
>> >> unfortunately
>> >> I've been trying to mesh my model with hexes (in Trelis)
>> without any
>> >> success. The model has the shape of a spherical cap and
>> >> apparently there
>> >> is something that Trelis doesn't like about this geometry. No
>> >> matter how
>> >> I divide and subdivide the model to help the mesher, there is
>> >> always one
>> >> volume that I cannot mesh. With tets, however, it works fine.
>> >>
>> >> Do you have any suggestions on what can I try to improve these
>> >> results,
>> >> without increasing the number of elements? I am at the limit of
>> >> resources in terms of the model size (right now I'm at 125 GB of
>> >> required memory to run my model). I could start using the HPC
>> but it
>> >> seems that there should be another way to solve this problem
>> >> other than
>> >> "brute force", i.e. making the model larger and using a bigger
>> >> computer.
>> >> You may also have suggestions regarding the meshing process. I
>> would
>> >> appreciate any advise that can help me to solve my problem. Let
>> >> me know
>> >> if there is any additional information you may need that I did
>> >> not include.
>> >>
>> >> Cheers,
>> >> Demián
>> >>
>> >> PS: I've attached the cfg files, just in case you want to see
>> >> how I'm
>> >> running the problem.
>> >>
>> >> --
>> >> *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-73
>> <%2B1%20%28901%29%20900-73>24>
>> >> email: 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>
>> >> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>> >> <http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-s
>> hort>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> Charles A. Williams
>> Scientist
>> GNS Science
>> 1 Fairway Drive, Avalon
>> PO Box 30368
>> Lower Hutt 5040
>> New Zealand
>> ph (office): 0064-4570-4566
>> fax (office): 0064-4570-4600
>> C.Williams at gns.cri.nz
>>
>> _______________________________________________
>> CIG-SHORT mailing list
>> CIG-SHORT at geodynamics.org
>> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>>
>
> <quality_profile.eps><stress_profile.eps><geometry.eps>_____
> __________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>
>
> Charles A. Williams
> Scientist
> GNS Science
> 1 Fairway Drive, Avalon
> PO Box 30368
> Lower Hutt 5040
> New Zealand
> ph (office): 0064-4570-4566
> fax (office): 0064-4570-4600
> C.Williams at gns.cri.nz
>
>
> _______________________________________________
> 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/20161018/2dce1bd2/attachment-0001.html>
More information about the CIG-SHORT
mailing list