Hello,
I would like to know if it is possible somehow to parameterize the input values for the geometry and mesh, instead of doing it manually for every element. And if it exists a way, which is the optimum way to do it. For example, we would like to define geometry values based on some parameters; for example, the position ‘X’ of a rectangle is defined by a parameter ‘W’, like ‘X=2*W’, where ‘W’ can have any value given apriori (for example the width of an element).
Other than that, I would appreciate if you can provide information on where and how to use “Tcl/Tk scripting language†in GiD, and if it would be helpful to this regard.
Thanks,
Eduard
GiD itself is not parametric, but for simple cases you could try two approachs:
a) write a batch text file with the ‘GiD process’ word commands to be done by GiD to create your simple shape.
Externally with some program you can automatically replace some values (e.g. width and height of a rectangle) that are your parameters.
Then to create the new shape you create the new specific batch file with its specific values, and evaluate this batch file in GiD
e.g. from the console command line:
gid.exe -b your_batch_file
or inside GiD from the menu Files->Read batch…
this allow you for example use GiD as a black-box in an external optimization loop.
b) write a Tcl procedure, intepreted inside GiD, that create your simple shape based on some parameters.
You can send GiD commands to GiD with our special GiD-tcl command GiD_Process, and also use other more specialized GiD-Tcl commands like GiD_Geometry to create or get information of geometrical entities.
You can invoke your Tcl code in several ways:
- Adding a macro button to the ‘macros toolbar’ to invoke your tcl procedure when clicking this button
- sourcing your .tcl file saved on disk, from the GiD lower command line, with
-np- source full_path_to_your_filename.tcl
- writting the code in a .tcl that is automatically sourced when loading the problemtype (this code could for example add your option to some menu)
About Tcl/Tk scripting in GiD, there is a lot of information available:
1- You could use all standard Tcl/Tk commands (Tcl 8.6.1), can see for example its manuals at: Tcl/Tk Manual Pages
2- Could use all standard Tcl packages included in our \scripts folder (find its information in the Internet)
3- GiD add extra commands, like GiD_Info, GiD_Process, etc. This commands are explained in our help: GiD Customization manual (see specially the Tcl-Tk extension chapter)
4- Have a look to our /scripts/dev_kit.tcl file, it has Tcl procedures of interest for GiD-Tcl advanced developers
5- We provide inside GiD ‘Ramdebugger’: a Tcl/Tk text editor and debugger (menu: Data->Problemtype->Debugger…)
The help of Ramdebugger includes the reference manuals of Tcl/Tk and some packages
6- In our web page http://www.gidhome.com/support/tutorials you can download the documentation of GiD courses of past GiD conferences. Some chapters have examples that explain thinks about GiD-tcl ,
read in special the chapters 8 (tool of mesh edition) and 9 (Debugging Tcl code) of the 2004 course
and the chapter A3 (Extending GiD with Tcl/Tk) of the advanced course of 2002
Thanks a lot, that sounds very helpful!
Hello,
In relation to your reply, I will trying making a “macro” with Tcl-Tk to parameterize the geometry; for example a “macro” to make a rectangle or a 3D volume. I’ve read that the RamDebugger, integrated in GiD, needs Tcl-Tk installed to work properly. My question is, do I first have to install Tcl-Tk and then install Gid? Or it will work anyway if I install Tcl-Tk afterwards?
Thanks,
Eduard
…I meant “should it will work anyway if I install Tcl-Tk afterwards?”. Because the fact is that it’s not working this way, so either I have to reinstall GiD or something is wrong.
Thanks,
Eduard
GiD has its own Tcl/Tk interpreter embedded, you don’t need to install anything more.
To start ramdebugger from inside GiD simple press the key or go to menu Data->Problemtype->Debugger…
This open the debugger, to start debugging press in ramdebugger.
(Ramdebugger could be loaded also in an external Tcl/Tk console. Can install Tcl/Tk from the ActiveTcl distribution but you don’t need it, GiD is self-contained)
Enrique
It happens that RamDebugger does not seem to debug (it does nothing) when executed from GiD (with or withous another Tcl/Tk installation). On the other hand, running Ramdebugger externally, as a stand-alone application, works fine and debugs fine. I’ve tried it with a “hello world” example.
I’m wondering if this is related to “debugging locally” or “debugging remotely”; as I’ve noticed some code has to be configured accordingly. Although I’ve tried that and it doesn’t work. Any idea? Inside RamDebugger, in File->Debug on I don’t see the options I should see to debugremotely.
Thanks,
Eduard
P.D: by the way, I’m using the professional evaluation version, which should be fully functional, right?
Starting RamDebugger inside GiD it works ‘debuggin locally’
Only if RamDebugger is started in an external process (e.g. installing another Tcl/Tk iterpreted, that is unneeded) then to debug GiD code must use ‘degugging remotely’, just to connect with the external GiD program.
Then GiD must be running and in RamDebugger must select:
File->Debug on->gid
(if ‘gid’ doesn’t appear try to use File->Debug on->Update remotes)
But the easiest way is start Ramdebugger in GiD and ‘debuggin locally’
for example, write a file with this code (write the code and save it to a filename) that must open a window whith “hello world”
proc my_test { } {
set text "hello world"
WarnWinText "text=$text"
}
my_test ;#to invoke it
Then you can set some stop for example in the line “WarnWinText” with the key F9 (or set it from menus)
and press or Debug->Continue/Go to start debugging
then when reaching this line the debug will stop and you can see/set variables, press again to continue
If do you edin and change the procedure at run time, could use Debug->Reinstrument to be sure that the procedure definition is updated.
Debugging locally, it doesn’t work. I’ve tested your “hello world” code and does nothing.
I also tried remotely, but it doesn’t work either. In menu “File->Debug on” there are only two options:
-Start debug
-Disconnect/stop
How can it be that RamDebugger does nothing?
Thanks,
Eduard
Actually, I have uninstalled it and reinstalled and still doesn’t work. The “begin/continue execution” button is in grey, seems not to be active.
Repeat this steps:
1- Download and install last GiD 12.1.2d (I am using the Windows x32 version, but could use other platforms)
2- Start GiD and go to menu Data->Problemtype->Debugger… (or press )
then ramdebugger must be opened
3- In ramdebugger open for example our GiD file scripts/Parametric.tcl
4- click the second line of the file “global ParametricPriv” and press a breakpoint with (or menu Debug->set breakpoint)
5- Press to start debuggin (the lower status bar of randebugger then show the word ‘debug’)
6- Go to GiD menu: Geometry->Create->Parametric line…
this command invoke the proc ParametricLine {} where the breakpoint was set, then the debugger must stop on this line, and you can investigate values, avance line by line with or continue with
It this doesn’t work then do you have some problem that I don’t know.
That worked wonderfully, although I have GiD version 12.03 (evaluation version). Then, how is that it doesn’t work with the “hello world” example you provided? Maybe I’m doing something wrong… I just open ramdebugger from GiD, copy your text and try to debug. The lower status bar of randebugger shows the word ‘debug’, but nothing happens.
Force the invocation of the procedure once it is ‘instrumented for debug’
e.g. write in the lower command entry
-np- my_test
(-np- is a special trick of this entry to say GiD that the line is a Tcl command, not GiD keywords to be processed)
or you can force the load of your file with the standard ‘source’ Tcl command:
-np- source {your_full_path_to_your_file.tcl}
Hello,
in relation to your first post, where you described the two approaches for parameterization (approach “a” and “b”), I would like to ask:
“a” - In this approach, we can’t run Tcl commands, right? Only GiD_Process commands, correct?
“b” - In this approach, how do we provide input arguments to the executed Tcl script?
In other words, what I would like to do is run GiD as a black-box, so that GiD interprets one Tcl script, and I can provide arguments to this Tcl script externally… and change them at every loop iteration. Which do you think would be the best approach?
Thanks,
Eduard
Option a) : you are right, the batch file is only a collection of GiD process commands, without any programming language.
Option b): you can invoke GiD from the command line with a -t <tcl_command> flag, to evaluate the command.
here you can see the command line options
http://www.gidhome.com/component/manual/referencemanual/general_aspects/invoking_gid
e.g. something like
gid.exe -t “MyCreateRectangle 10.1 5.4”
to evaluate the procedure MyCreateRectangle with parameters 10.1 and 5.4
The procedure must be first defined in GiD, for example because is one of our own procedures
You can load your own procedures in other ways, like put the files of your procedures in the \plugins folder
or directly source your file in the command line (source is a tcl standard procedure to load a tcl file)
e.g.
gid.exe -t “source {C:/tmp/my_file.tcl} ; MyCreateRectangle 10.1 5.4”
That sounds very very good!
Thanks,
Eduard
Hello,
I have tried the approach of invoking GiD from a batch file, specifying the Tcl procedure to run. It works great most of the times, however, when I make a FOR loop in the batch file to invoke GiD with a changing parameter, then sometimes (usually one in every 5 iterations) I get the following error:
“Error: ramdebugger not available: could not register port”
If I click on “Stack Trace”, it says:
“could not register port while executing. “error” could not register port” (procedure ::commR::register line13) invoked from within “comm::register gid 1”
Do you know how to solve this?
Also, in a FOR loop we have many instances of “gid” running in parallel; I have also noticed that the GiD processes are not killed after running the batch file. The GiD process is killed if I only run one instance of it (the Tcl code closes GiD), but not if I run many instances in the FOR loop.
Thanks,
Eduard
ramdebugger and GiD processes are connected trough a socket, and there is a limit in this number of ports, but I think that the error message must not be a problem, because probably you are not trying to be debugging a lot of GiD’s simultaneously.
The error said that the port can’t be opened, but I think that GiD will run normally but without the debug option.
I thinkt that this problem is just because you are starting a lot of GiDs and they are never ending, then the maximum ports is reached.
When do you start a GiD in batch mode you must be careful to exist the process at the end sending to GiD something like:
escape escape escape quit no
no is to answer the possible question of GiD to save a modified model.
else after doing all batch commands GiD will wait forever more commands
And another comment, if your Gids don’t require any graphical feature, like save pictures, then you can try to start GiD with -n flag to be faster (then the GUI is not showed)
Hello,
Thanks for your reply.
Actually I was already saving and then quitting GiD with the command you provided. I think the problem was the “ramdebugger” error, because GiD stops working. So what I did was commenting the following lines, in the “tclfile-opengl.tcl” file, so that Ramdebugger is not loaded:
set ramdebuggerinside 1 ;#1 if is included with GiD, all packages are inside scripts
if { $ramdebuggerinside } {
if { [catch {
package require commR ;#modification (commR) of tcllib comm package
comm::register gid 1
} err_txt] } {
set GidPriv(RamdebuggerMenuState) 0 ;#to hide it in menu
bgerror "ramdebugger not available: $err_txt"
} else {
bind all <F12> {
package require RamDebugger
}
}
} else {
#donde esta RamDebuger y tcl?
if { $tcl_platform(platform) == "windows" } {
lappend auto_path "E:/Programas/ActiveTcl8.4.9.0/lib"
set where_RamDebugger "C:/gid project/scripts/ramdebugger"
lappend auto_path ~/mytcltk
set where_ActiveTcl_lib {E:/Programas/ActiveTcl8.4.9.0/lib/tcl8.4}
} else {
set where_RamDebugger "/home/miguel/GID/stuff/RamDebugger"
set where_ActiveTcl_lib ""
}
# enter here the path where you have installed RamDebugger, subdirectory addons
# for example: c:\Program files\RamDebugger\addons
lappend auto_path [file join $where_RamDebugger addons]
package require commR ;#modification (commR) of tcllib package
comm::register gid 1
bind all <F12> {
# enter here the path where you have installed RamDebugger
# for example: c:\Program files\RamDebugger
lappend auto_path $where_RamDebugger
if { $where_ActiveTcl_lib != ""} {
lappend auto_path $where_ActiveTcl_lib
lappend auto_path [file join $where_ActiveTcl_lib tcl8.4]
}
package require RamDebugger
}
}
It works very well now, but maybe there’s a more elegant way of doing this? Although I’m happy with this solution.
Thanks,
Eduard
