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

Field.__call__ has inconsistent returns: use dictionaries #60

Closed
banesullivan opened this issue Jan 12, 2020 · 3 comments
Closed

Field.__call__ has inconsistent returns: use dictionaries #60

banesullivan opened this issue Jan 12, 2020 · 3 comments

Comments

@banesullivan
Copy link
Collaborator

banesullivan commented Jan 12, 2020

The __call__ method has different returns across Field subclasses... this is really messy. Would it be of interest to return a dictionary of numpy arrays in all cases?

For example, the krige classes return the field and the variance while all other field subclasses only return the field.

Using a dictionary with named arrays would help the user knows what's what when the arrays are returned and would be a lot cleaner, safer when capturing the output from different Field subclasses, and also make it seamless to add those arrays to either Meshio or PyVista meshes in Field.mesh

@banesullivan banesullivan changed the title __call__ has inconsistent returns: use dictionaries Field.__call__ has inconsistent returns: use dictionaries Jan 12, 2020
@LSchueler
Copy link
Member

I completely agree with you. I am currently working on a new interface for the variogram estimation.

I also stumbled upon the very messy handling of all the different fields and the return values. Therefore I introduced a new "data class" which is handed around and saves stuff like the position of the field values, all the different fields, ...
But the class will work very similar to a dictionary.

I have a totally unrelated dead line on Wednesday, thus I don't know how much I will get done, but I hope, that I can put up a PR soon in order to discuss in which direction to take things.

I'm still not sure whether to inherent all the different field classes from a data class or if they should have them as attributes. Let's see...

@banesullivan
Copy link
Collaborator Author

I like the idea of having a data class or just some standard structure like a dict to hold all of the data. Ping me when you are able to get a PR going as I'd be happy to help on that where I can

The use of dictionaries for this is fairly common in my experience. For example, SimPEG uses dictionaries to hold numpy arrays for data and models

@LSchueler
Copy link
Member

@banesullivan I just created a PR #65, where we can discuss things. I'd be more than glad to hear what you think about my suggestions.
I'll close this issue and we can continue the discussion in the PR.

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

No branches or pull requests

2 participants