It struck me as a need for future model generation, debugging, sharing, and visualization that there be a standard in terms of a model file I/O feature.
Let me motivate this by saying that a lot of the power in the usage of OpenSees is derived from the fact that it is built upon the tcl scripting language. This makes it possible to generate models based on hundreds of different source files, if/then statements, variable placeholders, for/while loops, functions, procedures, variable argument input/output procedures, lists, etc.... In fact it is general enough that different people working on the same project could each supply a tcl file to be sourced without having knowledge of the entire model. Therefore, there is a disconnect between the tcl input versus the actual input that the modelBuilder in OpenSees receives.
This raises the issue of how one would ever visualize models using such projects like Neesportal, OpenSeesNavigator, OSP, etc.... Obviously this is not possible given what is stated above. Then there is the issue of people submitting tcl input files for debugging/problem solving. Wouldn't it be nice to just see the OpenSees input and not all the tcl input? How about parametric studies, or models obtained from collaborators/third parties where there is not necessarily one input file that corresponds to a particular model.
Anyways, what I was proposing was a method for saving the model currently in the domain directly to file either as a.) a single input tcl file complete with commands (ie. element, uniaxialMaterial, etc) and values that could be sourced by anyone anywhere, or b.) a modified/simplified file format that just displays important information, coordinates, tags, arguments, etc but that could be imported into OpenSees at a later date or opened by post-processor/visualization routines, etc.
my two cents...
save as/print out feature
Moderators: silvia, selimgunay, Moderators
Interesting!
Very interesting thinking Kevin!
There are probably other issues that are related to data base of models, visualization...
A topic worth discussion. I allways thought of using XML to describe input, but have not had time to look into that so far. However, will be on sabatical next few quarters and will dwell into some of those issues.
I would appreciate more specific comments by others, perhaps define a small example that can be easily worked out (need to start somewhere...).
Boris
There are probably other issues that are related to data base of models, visualization...
A topic worth discussion. I allways thought of using XML to describe input, but have not had time to look into that so far. However, will be on sabatical next few quarters and will dwell into some of those issues.
I would appreciate more specific comments by others, perhaps define a small example that can be easily worked out (need to start somewhere...).
Boris
Re: Interesting!
This is indeed a good suggestion, and it is something that I had on my mind for while. The distinction in my view is "scripting" vs "model state". The model definition may be changing during an anlysis by adding/removing elements, materials, and it would be useful to be able to export that state from opensees at any point. I think we should have both the option to export to a database in order to be used with analysis of results. Additionally, one might need to export to a text file (xml or otherwise) for sharing with other applications or rerunning under opensees.
While it is theoretically possible for program like neesport or navigator to parse a tcl script and modify the model accordingly, it would certainly be easier not to have to worry about all the for/if/while clauses etc...
This can also help in debugging problems with OpenSees input files.
The sticky point with this is going to be whether to include any analysis commands in the output. I suspect that wasn't what Kevin intended, and I tend to agree with that.
mahmoud
While it is theoretically possible for program like neesport or navigator to parse a tcl script and modify the model accordingly, it would certainly be easier not to have to worry about all the for/if/while clauses etc...
This can also help in debugging problems with OpenSees input files.
The sticky point with this is going to be whether to include any analysis commands in the output. I suspect that wasn't what Kevin intended, and I tend to agree with that.
mahmoud