gid_offscreen

GiD Other
1

Dear GiD developers

Is it possible to set the path for problemtype in gid_offscreen command? Currently we have to calculate on a .gid file which was generated by the problemtype of the same name in gid/problemtypes folder. We can temporarily rename the current one but it’s more flexible to just set the path for the problemtype on the command.

Regards
Bui

2

I don’t understand your question at all.

It seems that your question is not related to use ‘gid_offscreen’ (a special compilation that allow to run GiD an create some graphics without any GUI) .
gid_offscreen has the command line options that another ‘normal gid’

It is possible to start GiD and automatically load a problemtype with
gid -p

When opening a GiD model that was saved using a problemtype, the problemtype automatically will be loaded also.

As general rules:

  • A problemtype must be located inside the \problemtypes GiD folder (else the path for it won’t be relative, and a model won’t find it other machines with programs copied in different locations!!).
  • Instead of the problemtype it is possible to use a link to it (e.g. to share a problemtype between several GiD versions), this is very common for developers.
  • The problemtype folder must be considered as ‘read only’ for final users, the problemtype must not try to write anything in its own folder!!

It seems that you are saving a model with the same ‘model name’ as the ‘problemtype name’, it is not?
This is not ilegal, but unrecommendable because could be confusing (specially considering that a problemtype is a folder with .gid extension also)
Off course you must not save any model inside the \problemtypes folder or GiD will try to load it considering that it is a problemtype.

3

Hi Escolano

Thanks for your clarification. In fact my problem is very simple:

  • I created the model using problemtype ExProbType
  • Some time later, some one modify my problem type and create another model with it. It’s conflicted with the original problemtype so I got error trying to open his model using my current problemtype
  • As you mentioned, I can re-symlimk to his problemtype but it’s a bit inconvenient and double work when I want to reuse my problemtype, since it has the same name

It is better if it’s possible to set the path of problemtype to gid_offscreen or we can provide the full path to it, e.x gid_offscreen -p /home/hbui/others/ExProbType.gid
As an intermediate solution, I created a script that call gid_offscreen, which create new symlink to GiD problemtypes folder and restore it after gid_offscreen is done.

Regards
Bui

4

If a problemtype is evolving along the time, it is possible to try to open a old model with the old problemtype data structure and try to convert the old data to the new structure (fields of conditions, materials, general data,…)
To do it you must use ‘transform’.

Data->Problemtype->Transform…
or load again the same Data->Problemtype, and a window will ask you to ‘reset to new problemtype’ (lost all old data and have the new definition) or ‘transform’ (try to match the old data to the new data preserving it)

The problem is that do you have two different problemtypes with the same name, and wihout any version number to identify them.
This is a design error!! (and loading the old model will try to load the new problemtype without any transform and this is a bug)

The simple approach to handle problemtype versions is to use a name based on the version
e.g.
ExProbType1.0
ExProbType1.1
…
But change the name of the problemtype and its inner files is a problem, specially if do you store your source files in some version repository (SVN, CVS, git, etc.)
A little better approach is to use an intermediate folder based on the version name
ExProbType_1.0\ExProbType
ExProbType_1.1\ExProbType
…

then the filenames of the problemtype doesn’t change, only the folder name that must not be stored in any repository.

The best approach is to store the version number in the .xml, without change
ExProbType (containing the file ExProbType.xml that store the version 1.0, 1.1,…)

And automatically when loading a model the problemtype compares the version name of the problemtype saved with the model, and the current problemtype version, and automatically invokes a transform if necessary to update the old data.

Could see (and copy) how is implemented this approach in some of our problemtypes (obtained from the menu Data->problemtype->Internet retrieve…)
e.g. SAP2000, OpenFoam,…