Open ghost opened 11 years ago
ghost
commented
11 years ago Please ignore the first commit (7796846) -- it was made on a branch that I accidentally made from the wrong place, which was a mistake. The latter commit (8b2e6bc) is on a branch (ki.occam_fixes) made from master, as we are supposed to be doing.
kujaku11
commented
11 years ago Is there still a bug?
On Fri, Nov 2, 2012 at 7:25 PM, nietky notifications@github.com wrote:
Please ignore the first commit (7796846https://github.com/geophysics/mtpy/commit/7796846) -- it was made on a branch that I accidentally made from the wrong place, which was a mistake. The latter commit (8b2e6bchttps://github.com/geophysics/mtpy/commit/8b2e6bc) is on a branch (ki.occam_fixes) made from master, as we are supposed to be doing.
— Reply to this email directly or view it on GitHubhttps://github.com/geophysics/mtpy/issues/20#issuecomment-10006012.
ghost
commented
11 years ago Still doesn't work
Unless I'm mistaken, nothing relevant has been changed in occamtools since I posted this. ?
Anyway so you can reproduce this yourself, here's an example and the files with the standard occam filenames: http://nbviewer.ipython.org/4032165/test_case.ipynb
kujaku11
commented
11 years ago Cool, I'll work on that today and hopefully have something working.
On Thu, Nov 8, 2012 at 4:21 AM, nietky notifications@github.com wrote:
Still doesn't work
1.
Running with the latest master (62930a1https://github.com/geophysics/mtpy/commit/62930a1e3a) doesn't work. Example sessions: http://nbviewer.ipython.org/4031816/and http://nbviewer.ipython.org/4031978/ 2.
Running with this branch, doesn't work, although it's better than the latest master because of the partial fixes I've committed here. Example: http://nbviewer.ipython.org/4032037/. The model file is still not being read correctly.
Unless I'm mistaken, nothing relevant has been changed in occamtools since I posted this. ?
Anyway so you can reproduce this yourself, here's an example and the files with the standard occam filenames: http://nbviewer.ipython.org/4032165/test_case.ipynb
— Reply to this email directly or view it on GitHubhttps://github.com/geophysics/mtpy/issues/20#issuecomment-10151803.
kujaku11
commented
11 years ago Ok, should have fixed the bugs which are now on the master branch, I probably should have put them on the ki.occam_fixes. One suggestion on making the occam files:
In the INMODEL file the NUMBER EXCEPTIONS 0 line would be better formatted with a colon between the string and number. Like NUMBER EXCEPTIONS: 0
the function will now look for either data or .dat for the data file. Naming it with the extension of .dat would be the ideal naming convention.
I haven't allowd for exceptions or fixed values in the mesh file, have you ever dealt with these? It would be nice to incorporate all that Occam has to offer.
Have you tried using the mask point function for interactive masking of points, just wondering if it works for other people.
On Thu, Nov 8, 2012 at 7:34 AM, Jared Peacock peacock.jared@gmail.comwrote:
Cool, I'll work on that today and hopefully have something working.
On Thu, Nov 8, 2012 at 4:21 AM, nietky notifications@github.com wrote:
Still doesn't work
1.
Running with the latest master (62930a1https://github.com/geophysics/mtpy/commit/62930a1e3a) doesn't work. Example sessions: http://nbviewer.ipython.org/4031816/and http://nbviewer.ipython.org/4031978/ 2.
Running with this branch, doesn't work, although it's better than the latest master because of the partial fixes I've committed here. Example: http://nbviewer.ipython.org/4032037/. The model file is still not being read correctly.
Unless I'm mistaken, nothing relevant has been changed in occamtools since I posted this. ?
Anyway so you can reproduce this yourself, here's an example and the files with the standard occam filenames: http://nbviewer.ipython.org/4032165/test_case.ipynb
— Reply to this email directly or view it on GitHubhttps://github.com/geophysics/mtpy/issues/20#issuecomment-10151803.
ghost
commented
11 years ago Ok, should have fixed the bugs which are now on the master branch, I probably should have put them on the ki.occam_fixes. One suggestion on making the occam files:
In the INMODEL file the NUMBER EXCEPTIONS 0 line would be better formatted with a colon between the string and number. Like NUMBER EXCEPTIONS: 0
The example model file in the Occam 2d manual doesn't have a colon.
the function will now look for either data or .dat for the data file. Naming it with the extension of .dat would be the ideal naming convention.
But this meant to be a general purpose module! People could have named their files anything, and again the manual does not say anything about requiring certain names.
I very very very very strongly think we must write code that requires only what is required, and not enforce conventions on people. The Occam software doesn't require it, and nor should we. Take code from my read_* functions if you like: they read any filename. https://github.com/nietky/phdtools/blob/master/phd_modules/oc2d.py
What if someone wants to use mtpy to look at hundreds of Occam modeling runs they've done where the data file is named some other way? Do we really want to make them search and replace a thousand times, breaking their existing relationships, for no obvious reason?
I haven't allowd for exceptions or fixed values in the mesh file, have you ever dealt with these? It would be nice to incorporate all that Occam has to offer.
I've always meant to but never got around to it. You're right, we should. I discovered the other day that you can't have a model block contain less than two mesh columns, something to do with that triangular subdivision in the mesh file. Still don't totally understand how that works.
Have you tried using the mask point function for interactive masking of points, just wondering if it works for other people.
Nope - you mean in your plotting code? That's what I was aiming at using here! ;-)
Thanks for looking at this by the way. I'm still trying to get a grip on your module so I can fix these myself :-/
I'm having quite a bit of trouble getting Occam2D classes to read in my existing Occam 2D runs.
Problems:
INMODEL, and the keyword argument provided for it in the constructor for Occam2DModel basically does nothing. I fixed this for at least my case...The last one is the problem I haven't been able to fix. I don't know the algorithm used and haven't been able to sort it out yet. The model file is here: https://gist.github.com/3997973#file_model.txt