Dear Roman, this doen't answer your questions directly but maybe you find it relevant or even useful. In the following link you can find my intent to add some abstraction layer on top of the getfem model: http://gggears.svn.sourceforge.net/viewvc/gggears/trunk/fem/ It supports bricks that are necessary for elasticity problems, so that you can describe a model in a text file and the code from the mentioned link will convert it into a real getfem model.
I think this could also be one solution in your case. Instead of using directly the getfem model class, just create your own model description class or syntax that supports a certain subset of bricks and then convert it to a getfem model. If the only input to the model is through this interface you can store all information that you need in your own classes, so that a more like unidirectional communication with the getfem model would be sufficient. Regards Konstantinos On Mon, 2011-09-05 at 05:47 +0200, Roman Putanowicz wrote: > Dear All, > > Recently I have started thinking about GUI components for GetFEM. > The aim of this GUI would be easier management of models, bricks, > etc. For instance I imagine a widget where I could see all bricks > added to a model and all variables associated with particular bricks > (sort of a tree view). > > I think that a central point of access to GetFEM data should be > getfem::model class. Given a reference to getfem::model object I should > be able to build graphical (GUI) representation of the model as well > as perform all sort of operations on it (like adding bricks, variables, > querying state, etc). > > Unfortunately getfem::model class shows some deficiencies from the > above point of view. For instance I haven't found an easy way of > querying how many bricks are added to a model (and I should know this > if I want correctly use a brick index). > This is easy to fix but there are other things related for instance > to model variables and their properties (scalar or not, FEM based or > not, etc.). > > Looking at the implementation of getfem::model one can see that most of > the information needed to conveniently build GUI for GetFEM based models > is stored in private structures: var_description and brick_description. > Unfortunately both are private ( I have found public declaration like > typedef var_description *pvariable; > but no way to get to var_description data). > The two main data members of interest 'variables' and 'bricks' are private. > > Now I have a couple of general questions: > 1) Has anyone attempted to build widgets for managing models bricks, etc.? > If yes what was your approach? > 2) What is better strategy for designing GetFEM model query interface: > a) add to getfem::model methods to extract atomic information about > bricks and variables > b) expose references to var_description and brick_description objects > (after turning the structures into classes and providing read > only interface to their data) ? > > With kind regards, > > Roman _______________________________________________ Getfem-users mailing list [email protected] https://mail.gna.org/listinfo/getfem-users
