Getting rid of processors

[germa89]

I could hard code the corresponding processor for each MAPDL command, so if that processor is not active, we automatically set it.

Getting the corresponding processors might be a bit complicated. We could use the docs, but that needs us to have the full docs.

[mikerife]

I really don't like this idea; not at all. I can see too many pitfalls. @mcMunich and @pmaroneh do you have any thoughts?
Mike

[germa89]

I can see too many pitfalls.

I would need some examples to fully understand your point of view. :)

[mikerife]

How about we can *get (or get_value) of frequencies, participation factors etc right after a modal solve. But if the /solu processor is exited then we loose that. Entering the post processor is just one step; need to read in a set of results. It's a waste of time to constantly finish/enter a processor for each command.

[pmaroneh]

My two cents:

• I share @mikerife 's concerns about how long would it take to always enter / exit a processor for each command
• Using PyMAPDL requires being proficient with MAPDL anyway, and MAPDL users will know how to enter the processors so I don't think we'll be adding much value here

[germa89]

I agree with you guys, we can discard this.

However i do not like that

we can *get (or get_value) of frequencies, participation factors etc right after a modal solve. But if the /solu processor is exited then we loose that

is quite subtle. I dont think that many people knows that exiting /SOLU processor cleans up that info. I didnt know.

Any idea or suggestion on how to "mitigate" that?

[mikerife]

Hey @germa89 If the /solu processor is closed then we can get into /post1 and post process the .mode file. I've no idea why the data is removed from memory/db when the /solu processor is closed. Could possibly go back to a time before either of us were born! Or in my case when I was still playing outside in the dirt.

[germa89]

Let's not going to fiddle with it then 🤣