Removing Reader dependency in Results module

[germa89]

As the title.

The key is to replace the class ansys-mapdl-reader.rst.Result by some class which provides the same interface. The complete lists of functions in that class are:

Show list of Result class functions

```text ELEMENT_INDEX_TABLE_KEYS ELEMENT_RESULT_NCOMP __annotations__ __class__ __del__ __delattr__ __dict__ __dir__ __doc__ __eq__ __format__ __ge__ __getattribute__ __gt__ __hash__ __init__ __init_subclass__ __le__ __lt__ __module__ __ne__ __new__ __reduce__ __reduce_ex__ __repr__ __setattr__ __sizeof__ __str__ __subclasshook__ __weakref__ _animate_point_scalars _animate_time_solution _bc_header _cfile _element_map _element_solution_header _extract_element_components _extract_node_components _extract_surface_element_result _is_cyclic _is_distributed _is_main _is_thermal _load_element_table _load_materials _load_section_data _map_flag _nodal_result _nodal_solution_result _nodfor _nodstr _plot_nodal_result _plot_point_scalars _read_components _read_result_header _result_nitem _result_pointers _result_solution_header _result_solution_header_ext _solution_header _store_mesh animate_nodal_displacement animate_nodal_solution animate_nodal_solution_set available_results cs_4x4 cylindrical_nodal_stress element_components element_lookup element_solution_data element_stress filename materials mesh n_results n_sector nodal_acceleration nodal_boundary_conditions nodal_displacement nodal_elastic_strain nodal_input_force nodal_plastic_strain nodal_reaction_forces nodal_solution nodal_static_forces nodal_stress nodal_temperature nodal_thermal_strain nodal_time_history nodal_velocity node_components overwrite_element_solution_record overwrite_element_solution_records parse_coordinate_system parse_step_substep pathlib_filename plot plot_cylindrical_nodal_stress plot_element_result plot_nodal_displacement plot_nodal_elastic_strain plot_nodal_plastic_strain plot_nodal_solution plot_nodal_stress plot_nodal_temperature plot_nodal_thermal_strain plot_principal_nodal_stress principal_nodal_stress read_record result_dof save_as_vtk section_data solution_info text_result_table time_values version write_tables ```

However, I'm planning to migrate only the public ones:

To migrate

• available_results
• cylindrical_nodal_stress
• element_components
• element_lookup
• element_solution_data
  This requires a mapping sort of:

   - EMS: misc. data
   - ENF: nodal forces
   - ENS: nodal stresses
   - ENG: volume and energies
  

• element_stress
• filename
• materials
• mesh
• n_results
• n_sector
• nodal_acceleration
• nodal_boundary_conditions
• nodal_displacement
• nodal_elastic_strain
• nodal_input_force
• nodal_plastic_strain
• nodal_reaction_forces
• nodal_solution
• nodal_static_forces
• nodal_stress
• nodal_temperature
• nodal_thermal_strain
• nodal_time_history
• nodal_velocity
• node_components
• overwrite_element_solution_record
• overwrite_element_solution_records
• parse_coordinate_system
• parse_step_substep
• pathlib_filename
• principal_nodal_stress
• read_record
• result_dof
• section_data
• time_values
• version
• write_tables

Next PR

Plotting PR

• animate_nodal_displacement
• animate_nodal_solution
• animate_nodal_solution_set
• plot
• plot_cylindrical_nodal_stress
• plot_element_result
• plot_nodal_displacement
• plot_nodal_elastic_strain
• plot_nodal_plastic_strain
• plot_nodal_solution
• plot_nodal_stress
• plot_nodal_temperature
• plot_nodal_thermal_strain
• plot_principal_nodal_stress

VTK PR

• save_as_vtk
  This is going to require a separate package.

To not migrate:

• cs_4x4 - I couldn't make it work locally, so I'm not porting it. It will raise a not implemented error.
• solution_info
  It doesn't make sense to be ported, because of this type of information is hidden in DPF.

   >>> rst.solution_info(0)
          {'cgcent': [],
           'fatjack': [],
           'timfrq': 44.85185724963714,
           'lfacto': 1.0,
           'lfactn': 1.0,
           'cptime': 3586.4873046875,
           'tref': 71.6,

• text_result_table
  Used for the text in the plots. Not porting it.

There are many methods which are duplicate from mapdl.post_processing, I will probably redirect one to another (I don't know which one should prevail, probably post-processing).

[codecov]

Codecov Report

Attention: Patch coverage is 64.69466% with 185 lines in your changes missing coverage. Please review.

Project coverage is 77.50%. Comparing base (673ee55) to head (15cdd1c).
Report is 928 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (673ee55) and HEAD (15cdd1c). Click for more details.

HEAD has 6 uploads less than BASE

Flag	BASE (673ee55)	HEAD (15cdd1c)
	6	0

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1300      +/-   ##
==========================================
- Coverage   85.55%   77.50%   -8.05%     
==========================================
  Files          45       47       +2     
  Lines        7587     8109     +522     
==========================================
- Hits         6491     6285     -206     
- Misses       1096     1824     +728     

[akaszynski]

Fundamentally, this all needs to be moved to DPF-Post and DPF post needs to have an even simpler API.

Right now we have:

• DPF-Core
• DPF-Post
• MAPDL-Post
• Legacy reader

I'd rather not make a 5th. There's a potential new hire that will work for the PyAnsys team on DPF-Post and I'd like him to work on this along with you.

[germa89]

On-hold for the moment until I see how pydpf-post develops.

[germa89]

Closing because I do not have the capacity for this. I think eventually we should use dpf-post for this.