mapdl.input and /INPUT harmonisation

[germa89]

As mentioned in: #1749

Currently, the mapdl.input signature:

https://github.com/pyansys/pymapdl/blob/c31f30c074f548dedb37f82b6c22d4b551e50d9d/src/ansys/mapdl/core/mapdl_grpc.py#L1559-L1568

is quite different from /input APDL command (raw mapdl.input):

https://github.com/pyansys/pymapdl/blob/bb276791919083bcf77e26237c6c1342615ed0f9/src/ansys/mapdl/core/_commands/session/run_controls.py#L192

I wonder if we should homogenise the API, making something like:

def input(self, fname,  ext="",  dir="",  line="", log="", verbose=False, progress_bar=False, time_step_stream=None, chunk_size=512, orig_cmd="/INP", write_to_log=True, **kwargs):

So the users can do:

mapdl.input(fname, ext, dir)

which might be more consistent with the current API.

[germa89]

Pinging @pyansys/pymapdl-maintainers @pyansys/pymapdl-developers

[koubaa]

At the very least, mapdl.input should throw an exception if it gets a kwarg that it doesn't recognize. It should tell the user that ext is not a recognized kwarg. I think as a python user this is my expectation in general, I can't do pd.DataFrame(mohamed=1).

With that being said - I do agree that it makes sense to support some the arguments of /INPUT by mapdl.input.

[germa89]

Yes. Both are very good points. If we are not supporting ext and some people might use it... we should raise an issue.

[akaszynski]

We should support the original INPUT API while providing extra kwargs for our gRPC backend.

[germa89]

Next minor release will have that approach.

[germa89]

I just need then @mikerife opinion... to be totally convinced of this approach.

[mikerife]

Hi @germa89 well I think most mapdl users would use the clever/lazy approach of just including the extension in the file name anyway. That being said I think the plan is the better approach (support original api while providing for grpc going forward).
Mike