freecad_dict format about qmt HOT 6 CLOSED

For point A - yes, it's required to be serialized. I actually changed this after many hours of debugging cryptic errors :). The problem was that all tests that had been run used a shared directory, which we don't want to assume using docker. Everything that a task needs we want to assume is either handed to it by previous task output (and is serializable) or is explicitly passed in through the options dictionary.

I agree with unifying the serialization routines and putting them somewhere. Perhaps in a new file in the data module? However, I think it's a good idea to (at this stage at least) require the user to explicitly serialize the data. The reason is that we want the options dictionary to really be the object that gets passed to _solve_instance. This makes debugging a lot easier. Maybe a compromise would be putting an explicit check to give a helpful error message if type str is passed in?

For B - I totally agree. part_name is obsolete now that the parts are objects. I noted this in a Todo when I noticed that wire shells actually targets parts now (rather than a str corresponding to the part name). Internally, I think that we always access the part_name's from the items in build_order, so it's important that the names of the step files correspond to the strings that are written in there.

Perhaps an easy fix for now would just be to make the label field be automatically set by the name of the Part3DData class being instantiated? That way we wouldn't break any dependencies.

from qmt.

I'll deal with the unified serialisation tomorrow.

I disagree with the rationale behind requiring the user to serialise manually. The debugging is clear enough (you get an additional big blob attr quite early along the way instead of at the very beginning) and the difference in user convenience and "example niceness" is substantial IMO.
In case you're firm on this, I will add a more helpful error message. If a user gets the idea to put in a string despite the current variable naming and us only showing examples that manually call serialize_fc_file, the current error cryptically complains about padding. (then again, auto-serialising in the init preempts this ;) )

Part3D.label holds the pretty human-given name of each part at construction (in the user run.py). Each part knows its own name.
This name is then added to Geo3DData.build_order during the construction of Geo3DData in the Geometry3D task, used as key in the Geo3DData.parts dict (since Kevin needs exactly that kind of access) and in the export naming.
The question about part_name and parts_dict here is resolved, the rest about build order pertains to #33.

from qmt.

My main concern about the FC file serialization is how the new, modified, options dictionary gets passed to the _solve_instance method. If you just override self.options in the init statement, then that should be fine. I just don't want some new object created that is then referred to later in _solve_instance. So if you had in mind just modifying self.options, feel free to go for it!

from qmt.

Just pushed a commit with unified serialisation.
Might break fenics related functionality: please test & fix.

from qmt.

Note: feel free to simplify serialise to serialize ;)

from qmt.

Looks good, thanks!

from qmt.