Setup of the module and class structures

[rosoba]

Transform the orignial Implementation running as oricrete into this new package including submodules for - crease pattern representation, crease pattern operators, reshaping processors, and goal and constraint function evaluators.

[rosoba]

Current status is the reimplemented CreasePattern class with some minor renaminig of property attributes. The question is if a class for a CreasePatternState should be introduced defining the state as a displacement vector u. This would be fine for displacement based problems but for angle based algorithms with dihedral angles defining the current state this would not be working. Maybe a distinction into CreasePatternUState and CreasePatternPsiState would do the job.

What are the consequences for the implementation of SimulationTask calling the goal functions and constraints? Currently, a SimulationTask the simulation. It normally calls the f(u) and G(u) values of the included constraints and goal functions. As a consequence the optimization algorithm using a crase pattern would have to set the trial state of a SimulationTask and then submit it to the constraints and shape functions::

cp.u = u for f in self.goal_functions: f(cp) ...

[rosoba]

The envisioned class hierarchy looks like:

FormingTask

• contains an initial state u_0 and a final state u_1
• contains a link to source object represented by the previous forming task.
• it is the basic node of the design pipeline, all other constituents of the pipeline use it as a base class.

SimulationTask

• extends the FormingTask with the notion of time line / time stepping.
• uses and configures a SimulationStep and drives it through the time range using the specified goals and constraints.
• contains the SimulationHistory

SimulationStep

• inherits from CreasePatternState and
• can transform the state to a new state for a specified time value (time increment)?

SimulationHistory stores the array of displacement states that were

• derived at the end of the SimulationStep.

SimulationView

• uses SimulationHistory for visualization

FindFormForGeometry is a SimulationTask (optimization of a crease pattern for geometric constraints) FindFormForLoad is a SimulationTask (optimization of a crease pattern for force flow) FoldRigidly is a SimulationTask (kinematic folding, folding to target surfaces) FoldToSurface is a SimulationTask governed by the rigid folding principles FoldDisplacementControl is a SimulationTask governed by the rigid folding principles

MappingTask

• inherits from FormingTask
• has no time or constraints or goals, it is the user manipulation with an object that mimic the physical manipulation with an object - rotate, move, copy, mirror, flip

MapToSurface is an MappingTask - can be used for an initialization Rotate is an MappingTask (has options for multiplicity - rotationally symmetric structures) Move is an MappingTask (has options for multiplicity - rotationally symmetric structures) Flip is an MappingTask

ExportTask

• inherits from ProcessingTask
• based on the source design task produces a derived object

GenerateSupportFrame

• inherits from ExportTask GenerateFEMesh
• inherits from ExportTask
• has options for a particular FE-software.

ImportTask

• does not fit into the picture.
• his might be a deficit of the proposed class hierarchy what is the source of the pipeline?

[rosoba]

Interfaces

IFormingTask

• gets its data from IFormedObject
• gets its data from a previous IFormingTask through the trait previous_task
• provides the IFormedObject to its successor_tasks IFormingTasks as a formed_object trait.

IFormingTask(s) constitute a FormingProcess. They can be chained. Each FormingTask has a previous forming task.

The FormingProcess starts with a FactoryTask, an instance of IFormingTask. FactoryTask represents a data source of the design pipeline (FormingProcess). It can be realized as a generator of a formed_object. Examples of factory tasks are CustomCPGenerator, YoshimuraCPGenerator, WaterbombGenerator

factory_task = YoshimuraCPGenerator(n_x = 3, n_y = 5, L_x = 3, L_y = 4)
perturb_task = MapToSurface(previous_task=factory_task, target_surfaces=[tf1])
fold_rigidly = FoldRigidly(previous_task=perturb_task, target_surfaces=[tf1, tf2])
adapt_cp = AdaptCPToSurface(previou_tasks=perturb_task, target_surfaces=[tf1, tf2])

Relation between ISimulationTask and IOptOperators

IOptOperator is a class evaluating some expression within the optimization problem. It needs access to all the characteristics of the formed object / crease pattern and to all control parameters of the forming task. Therefore, during these operators all get a handle - a reference to a ISimulationTask. The question is how restrictive the type checking should be. The ISimulationTask contains the control entities representing the target faces, dof_constraints, grab points for direct kinematic and shape control. It can also contain loads. The IOptOperator must pick up what is appropriate for the particular evaluation.