-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unknown AxiSEM3D running issue and Error locating source in mesh. #20
Comments
You cannot add a moment tensor in fluid. Use FLUID_PRESSURE instead. Unit can be considered as Pascal. mechanism:
# what: type of source mechanism
# type: string
# only: MOMENT_TENSOR, FORCE_VECTOR, FLUID_PRESSURE
type: FLUID_PRESSURE
# what: data for the source mechanism
# type: array of double
# note: 1) use [M11, M22, M33, M12, M13, M23] for MOMENT_TENSOR;
# [F1, F2, F3] for FORCE_VECTOR;
# [P] for FLUID_PRESSURE,
# where 123 stands for ZRT (vertical, radial, transpose)
# 2) if horizontal location is given by "latitude_longitude",
# the RT-axes are determined w.r.t. the north pole;
# the moment tensor of an earthquake then follows the same
# order as in the CMTSOLUTION format (globalcmt.org)
# 3) if horizontal location is given by "distance_azimuth",
# the RT-axes are determined w.r.t. the source (mesh axis)
data: [1e20]
# what: unit of data
# type: double
# note: use 1e-7 to convert dyn*cm (in CMTSOLUTION) to N*m
unit: 1e-7 |
Mind you. Are you sure you are adding an undulating interface between two fluid layers? I cannot see the physical background but maybe you have your own reasons. |
Many applications can exist for such cases, most prominently the entire
seismic industry: almost all of their production runs are still based on
acoustics. Ideally, there would be no assumption from our developmental
side as to what scenario might be plausible or not, as in most
likelihood our own imagination is the limitation.
Tarje
On 26/07/2021 15:29, Kuangdai Leng wrote:
Mind you. Are you sure you are adding an undulating interface between
two fluid layers? I cannot see the physical background but maybe you
have your own reasons.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUMH5FQOC37KNHSS6JJRKDTZVPKDANCNFSM5A42A52Q>.
--
<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>
Associate Professor of Geophysics
Dept. of Earth Sciences, Oxford University
South Parks Road, Oxford OX1 3AN; UK
www.earth.ox.ac.uk/people/tarje-nissen-meyer
<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>--<>
pronouns: he/him/his
|
Thank you Kuangdai and Tarje for the answer. And yes maybe the undulating boundary between fluid is not necessary. The stimulation now runs successfully. However all the recievers returns 0 in each traces. Wondering is there anything I'm setting wrong? Many thanks! |
Hi Kuangdai, We've managed to simulate a marine seismic shot in the cartesian mesh. This is the animation of 2s wave propagation in the fluid domain at one azimuthal slice. However, the left boundary looks a bit strange. The left boundary should be an unphysical boundary but seems a lot of energy is accumulated there. What do you think? animation.mp4Best, |
Can you deactivate the 3D model and use constant Nr=1, and redo the simulation and show the animation here? |
This is the wavefield after we deactivate the 3D model and use constant Nr=1. The edge oscillation still exists. The 1D model is also a fluid domain. animation.mp4 |
Reopen this |
animation setting; |
I think there could be an issue with computing displacement near the axis in fluid. In fluid, we actually compute pressure, so this issue does not affect far-field displacement results. Can you try channels: [P] to animate pressure instead of [U]? Let see if heal the problem. |
Thanks Kuangdai. I thought I'm plotting [P] in these animation already? you could check in the inparam.output file. |
I see. So let's check the next possibility. The wavefield may vary quickly near the axis, so using a downsampled mesh grid is probably not enough. Can you use FULL for GLL_points_one_edge instead of [0, 2, 4]? Also, in the post-processing, you need to connect all 25 GLL points to make 16 quads for animation. The following example connect 9 GLL points to make 4 quads for animation. You need to change the bit in the screenshot. |
This is another color normalisation of pressure from 0 to 1e+11. animation.mp4! |
The wavefield looks quite fuzzy, reminding me of another possible issue. What is the period of the mesh? For animation, we cannot use a delta function as source-time function and convolve and filter later, as we do for seismograms. For animation, we use mesh period as |
Yes this might be the issue. Our mesh period is 0.05s. indeed the 0.2 half duration is a bit longer. I will adjust this first. And in terms of the full GLL points, could you remind me of the mesh connectivity in that case, shall I modify the code as followed:
|
Yes, that's correct. |
It reminds me that in the previous animation, we've already set the half duration to 0. In this new 3D animation (still 9 points per element), we change the half duration to 0.05s to match the meshing period (20Hz). The wavefield of pressure indeed looks clearer. But the oscillation at the left boundary still exists. So you think this left boundary issue will not affect the far-field displacement results? animation.mp4 |
That looks better. I think this is a visualization problem. Seismograms should be correct. |
Hi Kuangdai,
I'm trying to simulate some marine seismology shots for the ocean boundary layer. We define two fluid layers with undulation in the cartesian model. AxiSEM3D reads the model well but seems to have some unknown map issues and errors locating the source in the mesh.
Could you help have a look?
Best wishes,
Zhi
Returing error:
This is our input directory:
04_Cartesian_ocean_topo_20Hz.zip
The text was updated successfully, but these errors were encountered: