I find it useful to use psmeca type moment tensor symbols to visualize strain(-rate) or stress tensors which may or may not have anything to do with earthquakes, in which case a linear scaling of the symbol size may be better, or required.
I was wondering if we could modify psmeca to accommodate this. I realize that there are a bunch of flags to modify the scaling, have them constant, etc., but in the end, it seems that the magnitude (i.e. ~log(moment)) is always used, like
This makes sense for earthquakes, of course, unless one wants to make the point how much bigger large events actually are, which can also be helpful for teaching.
In the attached difference log between today’s github psmeca.c and my suggested code version, I introduce a new flag, -Q, which does modify the scaling, and it is calibrated to not make the PS conversion flip out for huge symbols when run on a typical sort of gCMT datasets. This seems to work and I added a warning to lesson the surprise. psmeca_linear_scale_diff.txt (3.9 KB)
Could we add this modification to the git branch/does someone have a more elegant and general implementation?
Thanks!
T
PS: While I haven’t carefully checked I also wonder about the S flag and its norminal size. Where is that actually used/is that supposed to work like this?
We should be able to include this feature pretty quickly, but we may wish to implement it differently (rather than a new -Q, it will likely be added via a modifier to -M, for instance). Could you please open a feature request on GitHub instead and maybe preempt a few of our general concerns in the process:
What’s the reference moment? Your patch uses a reference moment of 10**26, but that may make no sense for your strain or stress tensor cases. Should this be an option, e.g. -M+s ?
For earthquake moment tensors, a linear scaling would seem to make little sense because the moment of an Mw 5 earthquake is about 32 times larger than that of an Mw4 earthquake, so would not the plot be useless?
I’ll try to code this up via an -M modifier and then file as a request like you suggest. Would be good to have an option to pass the normalizing moment.
Of course, huge differences in moment between magnitudes, but I use such plots to illustrate to 101 students where all the action is, and if you have a smaller region with only moderate magnitude differences, you can see some stuff (like how different size the symbols are!) However, the main application would of course be properties that don’t vary over many orders of magnitude.
This version of psmeca would seem to do the trick and uses -M as suggested. There’s probably a better way to handle the arguments (so that it doesn’t bomb for -M+s or -Ml+s without value, for example), but it seems to work. I’ll put that in as a request. psmeca_diff.txt (4.8 KB)
Thanks much! It probably says right there in that post, but I am not that familiar with git - should I do anything besides git pull and recompile for testing?
Then recompile and test. Would be great if you can make a short test script (see those in test/seis for what they typically look like) and share so we can add it to the test suite. We can polish it.
Once you are done and want to switch back to master, do
You could try: git checkout --track origin/seis-linear-scaling
If you are testing remote branches often, you may want to set your local repository to track all remote branches. Right now, it is only tracking the master branch.
Here is what I sent to someone else who was having the same problem, which worked for them:
Ok, I think the problem is that if you did a shallow clone (like instructed in the building.md file), it is not set up to track remote branches.
For me, if I type git config --list, the line for remote.origin.fetch is remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
If you see something like this instead: remote.origin.fetch=+refs/heads/master:refs/remotes/origin/master, it means that the local repository is not setup to track remote branches.
You can change that by running:
git remote set-branches origin '*'
After running that command, if you run git branch -r you should see a longer list.
Glad it worked, even if the size is sub-optimal The repo size is largely related to the tests, which help keep GMT stable but rely on postscript files which git was not designed to track. I added a potential solution to the agenda for the next community meeting and am hopeful that we can make progress on it soon.
Thanks, works great! I did a couple of tests, and I think all works as it should. There’s a minor issue in that the -S+f option gets interpreted as a font for size < 0 (and not switch off labeling as old style -Sm/ did), but that should not affect (m)any.
As for a silly (but perhaps in certain instance instructive) example of using linear scaling with moment for gCMTs, here’s the kind of plot you can get with
Thanks Torsten, could you share your tmp.mdat file so we can build a test script out of this?
As for the comment on -S+f, do you mean if you give -S+f-1 ?
The repo size is largely related to the tests, which help keep GMT stable but rely on postscript files which git was not designed to track. I added a potential solution to the agenda for the next community meeting and am hopeful that we can make progress on it soon.