Doing a problem type in python

Moderator: GiD Team

Post Reply
Daniel
Posts: 20
Joined: Fri Feb 03, 2023 4:08 pm

Doing a problem type in python

Post by Daniel »

First of all I want to thank the answers in this forum.

So, I am struggling to make a problem type. Because of this, I would like to know the strictly necessary files to make a problem type, since this link:

https://gidsimulation.atlassian.net/wik ... ementation

says that 'most files are not compulsory'. Also, I would like know a simple example with the problem type written in python (instead of Tcl/Tk), since:

https://gidsimulation.atlassian.net/wik ... hon+in+GiD

says it is possible.

Thanks in advance.
Daniel.
User avatar
escolano
Posts: 1918
Joined: Sun Sep 05, 1982 10:51 pm

Re: Doing a problem type in python

Post by escolano »

About the compulsory files, there are two kind of GiD problemtypes:
a) customLib (with a tree showing the problemtype-data and a XML DOM storing its information)
Documentation: https://gidsimulation.atlassian.net/wik ... YPE+SYSTEM
Example: https://gidsimulation.atlassian.net/wik ... OBLEM+TYPE

b) classic (different windows for conditions, materials, problemdata,...)
Documentation: https://gidsimulation.atlassian.net/wik ... mtype+system
Example: https://gidsimulation.atlassian.net/wik ... ementation

In fact is possible to mix features of both kinds to store or write your data.

In both cases must exists inside $gid/problemtypes a folder with a name and .gid extensions, and inside some files with same name and other extensions.
In general any file is compulsory, but if you define nothing you will have a valid but empty problemtype.

a) basically the only required file is the $name.spd, that is an XML where the tree is defined
but usually you will want to export all information of the tree, mesh, groups,... in the calculation files, and this is done by the file $name.tcl with some Tcl procedure that ask information to GiD and print it with the desired syntax (Tcl is the scripting language used by GiD, and Tk a Tcl library to create the GUI)

b) instead the single .spd in this case are different files .cnd for conditions, .mat for materials, .prb for general data, .uni for extra units
usually to export were used .bas files, that are templates with a simple GiD syntax
but is is possible (and maybe necessary for very complex cases) to export the information with Tcl procedures

If do you want to expand more your problemtype modifying the GUI, must do it with Tcl/Tk procedures. You can modify all you want: menus, toolbars, create your own windows,... but this is not compulsory
User avatar
escolano
Posts: 1918
Joined: Sun Sep 05, 1982 10:51 pm

Re: Doing a problem type in python

Post by escolano »

About the second question, if it is possible to write a problemtype in Python.

The .spd (customlib) or .prb, .cnd, .mat, .uni are not any programming language (I don't consider XML as a language)
They are not Tcl or Python.

But from these description files GiD is building its GUI tools: the tree and different windows, and all this is implemented in Tcl/Tk, not in Python (but is implemented by us, the GiD developers, not by a problemtype developer or its final user)

About writing the calculation files, instead use a Tcl procedure technically is possible to write a Python procedure, but I don't recommend it at all: The Python function will ask GiD its information through Tcl in a similar syntax that doing directly in Tcl. Can reorder this information and print it with its methods, but doesn't has any advantage compared with the Tcl alternative (if fact has a several drawbacks to debug, performance, etc.)

About changing the GUI and creating new windows, Python is a pure console scripting, like Tcl. And all GiD GUI are Tk objects, Python has nothing to do with it (at least better than Tcl). Maybe using the TkInter Python library is possible, but in any case this is a wrapper of the true Tk library. (why do in in Python that call TkInter that call Tcl that call Tk. Is is better use directly Tk)

The main current use of Python in GiD is for console (non GUI) features.
To have access to his big amount of available modules that can to a lot of things not available in the Tcl small ecosystem (e.g read medical image formats, use other NURBS libraries, other CAD libraries, Artificial Intelligence libraries,...).
Or to avoid to rewrite you own existent Python code in Tcl to be used in GiD.

It is possible from tcl call Python procs and vice-versa from the Python interpreter call commands of the Tcl interpreter
Post Reply