Skip to content
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

Bugs in Occam2D classes #20

Open
ghost opened this issue Nov 2, 2012 · 6 comments
Open

Bugs in Occam2D classes #20

ghost opened this issue Nov 2, 2012 · 6 comments
Labels

Comments

@ghost
Copy link

ghost commented Nov 2, 2012

I'm having quite a bit of trouble getting Occam2D classes to read in my existing Occam 2D runs.

Problems:

  1. Windows paths with colons in the startup/iter files break the read2Diter method. I fixed that in at least the one place where I found it.
  2. Code assumes model files are called INMODEL, and the keyword argument provided for it in the constructor for Occam2DModel basically does nothing. I fixed this for at least my case...
  3. read2DInmodel() doesn't properly read the valid model file I'm using

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

ghost pushed a commit that referenced this issue Nov 2, 2012
* Handle inmodelfn != INMODEL for Occam2DModel constructor
* Handle Windows paths in iter/startup files
* Occam 2D example has no colon after 'NUMBER EXCEPTIONS'
* More information get2Dmodel error message
@ghost
Copy link
Author

ghost commented Nov 2, 2012

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
Copy link
Collaborator

kujaku11 commented Nov 7, 2012

Is there still a bug?

On Fri, Nov 2, 2012 at 7:25 PM, nietky [email protected] wrote:

Please ignore the first commit (77968467796846)
-- 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//issues/20#issuecomment-10006012.

@ghost
Copy link
Author

ghost commented Nov 7, 2012

Still doesn't work

  1. Running with the latest master (62930a1) 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

@kujaku11
Copy link
Collaborator

kujaku11 commented Nov 7, 2012

Cool, I'll work on that today and hopefully have something working.

On Thu, Nov 8, 2012 at 4:21 AM, nietky [email protected] wrote:

Still doesn't work

Running with the latest master (62930a162930a1e3a)
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//issues/20#issuecomment-10151803.

@kujaku11
Copy link
Collaborator

kujaku11 commented Nov 7, 2012

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 [email protected]:

Cool, I'll work on that today and hopefully have something working.

On Thu, Nov 8, 2012 at 4:21 AM, nietky [email protected] wrote:

Still doesn't work

Running with the latest master (62930a162930a1e3a)
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//issues/20#issuecomment-10151803.

@ghost
Copy link
Author

ghost commented Nov 7, 2012

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 :-/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant