@marioalexis84 Could you take a look at this? The input file is written properly and the analysis is submitted but when it's set to pure heat transfer, there's an error on reading results:

15:29:39  Running the Python command 'FEM_SolverRun' failed:
Traceback (most recent call last):
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femcommands/commands.py", line 1174, in Activated
    run_fem_solver(self.selobj)
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femsolver/run.py", line 108, in run_fem_solver
    fea.run()  # standard, no working dir is given in solver
    ^^^^^^^^^
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femtools/ccxtools.py", line 688, in run
    self.load_results()
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femtools/ccxtools.py", line 808, in load_results
    self.load_results_ccxfrd()
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femtools/ccxtools.py", line 818, in load_results_ccxfrd
    importCcxFrdResults.importFrd(
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/feminout/importCcxFrdResults.py", line 154, in importFrd
    res_obj = resulttools.compact_result(res_obj)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/ubuntu/Documents/squashfs-root/usr/Mod/Fem/femresult/resulttools.py", line 663, in compact_result
    new_node_numbers.append(node_map[old_node_id])
                            ~~~~~~~~^^^^^^^^^^^^^

(0,)

I would expect it to fail because there are no mechanical results in this analysis (only temperature) but the errors suggest issues with node numbering for some reason.

The generated .frd file is correct, I can open it with other postprocessors.

can you share your test file?

can you share your test file?

Sure, here's the file:

Cube heat.zip

I only get the loading result failed error after writing and running, but not the stack trace that you share.

@marioalexis84 you can temporarily remove the try except block here to get the stack trace

Getting the same error as @FEA-eng

I didn't mean to avoid the loading error, just reproduce the one reported by @FEA-eng .

You won't avoid it, on the contrary, you will get the stack trace, since you would no longer catch the exception

By removing try except block I meant to leave bare self.fea.load_results()

Now I understand. I misunderstood your comment before being edited.

Sorry for the confusion, glad it's been cleared up

@FEA-eng, I guess, I tracked it down to this code

This is what I get, when running result_set.keys() inside the above mentioned function. And there are no "disp" results indeed

dict_keys(['number', 'time', 'temp'])

If we had "disp" in result_set, we would've set res_obj.NodeNumbers. Since we don't have "disp", the NodeNumbers are the default ones - [0]

In other two modes, we have "disp" in result_set.keys()

I did as it was written in the comments for the above mentioned function and made a PR (FEA-eng#1) to your repo. With these changes I managed to get a result:

However, if I try to move the "displacement" slider, I get the following error

Traceback (most recent call last):
File "..\Mod\Fem\femtaskpanels\task_result_mechanical.py", line 612, in show_displacement
    self.mesh_obj.ViewObject.setNodeDisplacementByVectors(
IndexError: list index out of range

So I guess, a user shouldn't be able to activate the displacement slider, if there are no displacements

I did as it was written in the comments for the above mentioned function and made a PR (FEA-eng#1) to your repo. With these changes I managed to get a result:

Thanks a lot, PR merged. The issue with the slider is not that bad, maybe we could even fix it separately if it's hard to do now. @marioalexis84 What do you think?

Ok to me.

In a next PR we can add the heat flux variable to the .inp writer and to the .frd reader.

In a next PR we can add the heat flow variable to the .inp writer and to the .frd reader.

Do you mean #12117 ? Yes, that could be the next step. I've tried to add this some time ago but I've only managed to prepare a code that will write HFL to the input file:

but supporting it in results objects will be more tricky. Especially since it's a vector quantity.

Do you mean #12117 ?

I will work on it as soon as possible.