Feat/issue 504 nearest #540
Conversation
| >>> mapdl.block(0, 10, 0, 10, 0, 10) | ||
| >>> mapdl.esize(3) | ||
| >>> mapdl.vmesh('ALL') | ||
| >>> q = mapdl.query() |
There was a problem hiding this comment.
Thought about this more and I think this should be an attribute. That way it matches the rest of our API and we can do this:
node_number = mapdl.query.node(5, 5, 5)You'll also be able be able use autocomplete/intellisense right on mapdl.query, making it easy to inspect the attr for available methods.
There was a problem hiding this comment.
I've also been thinking about this and I've realised what I don't like about query as a property. It's more to do with the word itself. Query is a verb and a noun, so I find I expect one usage and see another, which I really don't like. I think some other name would be more appropriate, that is less ambiguous. E.g.
querierorqueriesfunctions- since we are providing access to the APDL functions after all, I think this would make most sense and be the most intuitivequery_service- most accurate, but longest
There was a problem hiding this comment.
I'm out of the office, but this has been eating away from me.
I feel like queries fits best here. We're effectively providing a collection of methods to allow the user easier access to MAPDL *GET methods.
node_number = mapdl.queries.node(5, 5, 5) # BTW, IMO should be "node_num_from_coord"functions isn't the best fit since we're already providing access to MAPDL functions like K, VPLOT, VGET, etc. Queries makes a bit more sense since we're querying the database for certain values.
Let's merge this PR and create a new one refactoring this if you're fine with queries. Otherwise, we can continue the discussion here or on teams.
NNEAR
KNEAR
ENEARN