New more pythonic real constant and element type keyopt objects?

[natter1]

Not sure if this is a good idea. I find the handling of real constants and keyopts a big hassle, esp. as they are different for each element type. So why not use objects to handle this? Something like RealConstants172 or KeyOpts186. They could handle all values including a short doc-string description.

[akaszynski]

Not sure if this is a good idea. I find the handling of real constants and keyopts a big hassle, esp. as they are different for each element type. So why not use objects to handle this? Something like RealConstants172 or KeyOpts186. They could handle all values including a short doc-string description.

Good idea. An element type class would be even better. A class for each element would be a pain to program, but we could likely autogenerate something.

[natter1]

First draft of scraping data from html docu-files.

• Class to read in data and generate class
• example result for conta172

This creates a class Conta172 with all real constants plus properties with doc-string. The method call_r()to set all these real constants is still missing. I think the keyopts are way more challenging. Ideally each keyopt would be turned in an Enum with all the allowed options. But its much harder to auto-scrap, and also to find good names (as its just numbers in APDL).

What other functionallity should be part of an element class object?

[akaszynski]

I'm going to contact some people internally within Ansys to see if there's a better way of doing this other than scraping external (and old) docs. I've been refactoring the docs in #446, and it's not something that can be done manually; it must be automatic. Since those tables are generated from XML, I'm imagining that the actual XML source will be easier to work with since tables from HTML are a nightmare.

For now, I think the prototype class is a good first attempt, and if I can't get help for this internally we can try to improve the scraper. I don't think it will come to that.

[natter1]

I'm imagining that the actual XML source will be easier to work with since tables from HTML are a nightmare

For the real constants, the tables are not so bad, but I agree, working with the original xml data should be prefered if possible. Imho the real nightmare would be the keyopts, as they are not in a neat table at all ;D

So for now lets focus on what the elemeent-class should be able to do and how it should look like. Its no prob to replace the data scraping method later.

You also mentioned automating the linking to other mapdl-comands in #446. I agree, this should be automated. One thing I'm not so happy with is the readability when using the doc-string (and not the sphinx-generated documentation). Thats an additional reason, why we should not use \ for tailing '_', its confusing. Linking to other commands should be ok, if its short enough (which is not true, if its e.g. a method of a different class/module). Maybe its possible to do it only for the sphinx doc generation, instead of replacing it inside the doc-strings? Not sure if it is possible to do such an additional step with sphinx.

[akaszynski]

One thing I'm not so happy with is the readability when using the doc-string (and not the sphinx-generated documentation). Thats an additional reason, why we should not use \ for tailing '_', its confusing.

I find that as well. There's a balance between the sphinx docs and docstrings within numpy. We can actually generate a documentation class that's just used for documentation for sphinx rather than using one single docstring for both sphinx and the python source. Ideally there would be only one, but many of these commands are quite complex and it's difficult to place all the documentation in one spot.

Let me know if you can think of a solution to this problem.

[natter1]

516