signature of solver writer class

[bernd]

The signature of the input writer class has not been changed since release 0.17 thus I would not like to change it on adding new FEM objects. We need to find a solution for this. https://github.com/FreeCAD/FreeCAD/blob ... py#L37-L60 and https://github.com/FreeCAD/FreeCAD/blob ... py#L42-L65

This post was the starting point for this problem. https://forum.freecadweb.org/viewtopic. ... 20#p298033

I had a german conversation with Markus the dev of elmer solver. I will copy it here.

[bernd]

in bezug auf das laden alter dokumente habe ich aktuell probleme eher beim blick in die zukunft, weil ich noch nicht weiss wie ich die api konstant halten soll wenn neue FEM-objekte dazukommen. In Calculix werden die objete im task modul collected und dann an den writer übergeben. Kommt da ein object dazu, ändert sich die writerklasse und alte dateien würden nicht mehr laden. In Elmer hast du das anders gelöst, da collectest du die objekte erst im writer, aber dann müssen sie in pre-checks, und allen anderen tasks immer wieder collected werden, dass ist auch nicht smart, oder? Ich habe testweise dein verhalten für calculix implementiert, bin aber wie gesagt auch nicht so richtig davon überzeugt. https://github.com/berndhahnebach/FreeC ... bercollect

Wie siehst du dass denn?

Bin mir jetzt nicht ganz klar was du meinst. Die Writer Klasse ist ja kein DocumentObject also sollten die alten ohne probleme laden oder? Falls ich es richtig verstehe meinst du dass man dann die Simulation nicht mehr ausführen kann weil sich der writer (bzw. calculix.tasks._Container) Objekte erwartet die es in der "alten" Analysis nicht gibt?

ja du hast vollkommen recht, habe zu schnell geschrieben. Das problem besteht, wenn jemand ein macro programmiert wel hes die writerklasse benutzt. Aktuell läuft die mit 0.17, 0.18 und 0.19. Aber ich habe noch einen PR am laufen, der neue objecte hinzufügt. Spätestens da muss ich das lösen. Evtl eine lösung wäre eine klasse die objekte beinhaltet, und diese als attribut übergeben, oder wie in elmer in jedem task des gask modul die objecte neu collecten.

was meinst du

Achso, also ist das Problem ist die Signatur von dem Konstruktor von FEMInputWriterCcx oder? Die eigentliche Frage ist ja jetzt wo wir die collect logik haben wollen. Die collect logik muss wissen welche Objecte benötigt werden welche optional sind und so weiter. Ich würde sagen der beste Platz dafür ist der Writer. Dann kann man auch den Prepare task ein wenig einfacher und generischer halten. Die collect logik im write kann man dann auf verschiedene Arten implementieren. Mein Vorschlag wäre wie folgt (easy) aber du kannst natürlich auch deine _Container Klasse verwenden.

Code: Select all

import femtools.femutils as femutils

class FemInputWriterCcx(writerbase.FemInputWriter):
    def __init__(analysis, solver, dir_name):
        data = collect(solver)
        writerbase.FemInputWriter.__init__(
                self, analysis, solver,
                data["mesh"],
                data["matlin_obj"],
                ...
                dir_name)

    def collect(solver):
        data = {}
        data["mesh"], message = femutils.get_mesh_to_solve(self.analysis)
        data["matlin"] = femutils.get_several_member('Fem::Material')
        data["matnonlin"] = femutils.get_several_member(
                'Fem::MaterialMechanicalNonlinear')
        ...
        return data

Damit ist auch das Interface zu FemInputWriterCcx fixiert. Den alten Konstruktor kann man beibehalten falls es notwendig ist für Macros. Falls FemInputBase auch ein stabiles Interface haben soll könnte man das dict direkt übergeben oder die collect logik in FemInputBase verschieben.

[bernd]

I myself did some development around a year ago in this regard. https://github.com/berndhahnebach/FreeC ... it/1cf9dc4 But I am not 100 % convinced this is the way to go, thus I did not merge it.

The latest dev in this regard can be found here: https://github.com/berndhahnebach/FreeC ... bercollect

[bernd]

mainly I see two solutions

- collect all member in a class and give the class from every solver task to the next one

- collect all member again in each task

Furthermore another desicion needs to be made:

- collect all member for every solver (general collector method)

- let a solver only collect his members (solver dependend collector method)

[bernd]

noone any comments here

[reox]

can not really make any good comment here, but do you know **kwargs? If you are concerned with the number of arguments and older versions not knowing of them, keyword arguments as dict can solve this to some extend.
Or you create some class which holds all the parameters and pass it to the objects who need them.

[ebrahim raeyat]

noone any comments here

@bernd it seems it is a profesional decision and i think if i start to implement opensees solver, perhaps i could help on this topic.
i continue implementation on it's related topic and please help me on this way. at first i want to implement beamcolumn element, and for mesh, i will work on it later. thanks

[bernd]

great !

updated my branch to another much simpler approach ... https://github.com/berndhahnebach/FreeC ... bercollect

The first implementation was moved to https://github.com/berndhahnebach/FreeC ... bercollect

[ebrahim raeyat]

great !

updated my branch to another much simpler approach ... https://github.com/berndhahnebach/FreeC ... bercollect

The first implementation was moved to https://github.com/berndhahnebach/FreeC ... bercollect

thanks @bernd. i have app image of freecad. how can i download only your change in FEM workbench? excuse me for my elementary question

Code: Select all

OS: Ubuntu 18.04.4 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19566 (Git)
Build type: Release
Branch: master
Hash: 9960b673997a926c101b8b61a65e8d3796664c01
Python version: 3.8.1
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

[bernd]

this is related to git workflow. Would be good to open a new topic. For my sake in FEM. We could discuss it over there. FYI. No need to hurry with this in the regard of any of your development for opensees solver. This may changes until it will get into master. As soon as some of this is in master I will update my oofem branch. You could than copy from there just once.

cheers bernd