LabRPS Scripting Basics: Difference between revisions
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Docnav | {{Docnav | ||
|[[Python_scripting_tutorial|Python scripting tutorial]] | |[[Python_scripting_tutorial|Python scripting tutorial]] | ||
|[[ | |[[PySide|PySide]] | ||
}} | }} | ||
| Line 8: | Line 8: | ||
==Python scripting in LabRPS== | ==Python scripting in LabRPS== | ||
LabRPS is built from scratch to be totally controlled by Python scripts. Almost all parts of LabRPS, such as the interface, the | LabRPS is built from scratch to be totally controlled by Python scripts. Almost all parts of LabRPS, such as the interface, the document contents, are accessible from the built-in Python interpreter or from your own scripts. As a result, LabRPS is probably one of the most deeply customizable engineering applications available today. | ||
If you are not familiar with Python, we recommend you search for tutorials on the internet and have a quick look at its structure. Python is a very easy language to learn, especially because it can be run inside an interpreter, where simple commands, right up to complete programs, can be executed on the fly without the need to compile anything. LabRPS has a built-in Python interpreter. If you don't see the window labeled '''Python console''' as shown below, you can activate it under the {{MenuCommand|View → Panels → Python console}}. | If you are not familiar with Python, we recommend you search for tutorials on the internet and have a quick look at its structure. Python is a very easy language to learn, especially because it can be run inside an interpreter, where simple commands, right up to complete programs, can be executed on the fly without the need to compile anything. LabRPS has a built-in Python interpreter. If you don't see the window labeled '''Python console''' as shown below, you can activate it under the {{MenuCommand|View → Panels → Python console}}. | ||
| Line 51: | Line 51: | ||
===The App and Gui objects=== | ===The App and Gui objects=== | ||
As already mentioned, in LabRPS everything is separated into core and representation. This includes the | As already mentioned, in LabRPS everything is separated into core and representation. This includes the RPS Features. You can access defining properties of objects (called features in LabRPS) via the {{incode|App}} module, and change the way they are represented on screen via the {{incode|Gui}} module. For example, a wind velocity simulation has properties that define it (like number of process, frequency discretization, power spectral density function) that are stored in an {{incode|App}} object, and representation properties (like whether to be shown in the tree view) that are stored in a corresponding {{incode|Gui}} object. | ||
This way of doing things allows a very wide range of uses, like having algorithms work only on the definition part of features, without the need to care about any visual part, or even redirect the content of the document to non-graphical application, such as lists, spreadsheets, or element analysis. | This way of doing things allows a very wide range of uses, like having algorithms work only on the definition part of features, without the need to care about any visual part, or even redirect the content of the document to non-graphical application, such as lists, spreadsheets, or element analysis. | ||
| Line 87: | Line 87: | ||
===The Document objects=== | ===The Document objects=== | ||
In LabRPS all your work resides inside documents. A document contains your | In LabRPS all your work resides inside documents. A document contains your simulations and can be saved to a file. Several documents can be opened at the same time. The document, has {{incode|App}} and {{incode|Gui}} objects. The {{incode|App}} object contains your actual features definitions, while the {{incode|Gui}} object contains the different views of your document. You can open several windows, each one viewing your work with a different visualization methods. These views are all part of your document's {{incode|Gui}} object. | ||
To access the {{incode|App}} part of the currently open (active) document, you type: | To access the {{incode|App}} part of the currently open (active) document, you type: | ||
| Line 117: | Line 117: | ||
==Using additional modules== | ==Using additional modules== | ||
The {{incode|LabRPS}} and {{incode|LabRPSGui}} modules are only responsible for creating and managing objects in the LabRPS document. They don't actually do anything more such as creating or modifying features. This is because that feature can be of several types, and therefore requires additional modules, each responsible for managing a certain feature type. For example, the [[ | The {{incode|LabRPS}} and {{incode|LabRPSGui}} modules are only responsible for creating and managing objects in the LabRPS document. They don't actually do anything more such as creating or modifying features. This is because that feature can be of several types, and therefore requires additional modules, each responsible for managing a certain feature type. For example, the [[SeismicLab_Workbench|SeismicLab Workbench]], is able to generate seismic ground motion by allowing the creation and the modification of SeismicLab features. Whereas the [[WindLab_Workbench|WindLab Workbench]] is able to build and modify random wind velocity features. In this manner LabRPS is able to handle a wide variety of object types, that can all coexist in the same document, and new types can easily be added in the future. | ||
{{Top}} | {{Top}} | ||
| Line 132: | Line 132: | ||
{{Code|code= | {{Code|code= | ||
mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName") | |||
}} | }} | ||
The first argument is the object type, the second the name of the object. | The first argument is the object type, the second the name of the object. | ||
{{Top}} | {{Top}} | ||
| Line 150: | Line 144: | ||
{{Code|code= | {{Code|code= | ||
mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName") | |||
mySimulation.TimeIncrement= 0.25 | |||
}} | }} | ||
| Line 174: | Line 160: | ||
or check if an object is derived from one of the basic ones ( | or check if an object is derived from one of the basic ones (Simulation, WindLab Feature, etc): | ||
{{Code|code= | {{Code|code= | ||
print(myObj.isDerivedFrom(" | print(myObj.isDerivedFrom("WindLab::WindLabFeature")) | ||
}} | }} | ||
| Line 187: | Line 173: | ||
{{Docnav | {{Docnav | ||
|[[Python_scripting_tutorial|Python scripting tutorial]] | |[[Python_scripting_tutorial|Python scripting tutorial]] | ||
|[[ | |[[PySide|PySide]] | ||
}} | }} | ||
Latest revision as of 19:18, 29 October 2024
Python scripting in LabRPS
LabRPS is built from scratch to be totally controlled by Python scripts. Almost all parts of LabRPS, such as the interface, the document contents, are accessible from the built-in Python interpreter or from your own scripts. As a result, LabRPS is probably one of the most deeply customizable engineering applications available today.
If you are not familiar with Python, we recommend you search for tutorials on the internet and have a quick look at its structure. Python is a very easy language to learn, especially because it can be run inside an interpreter, where simple commands, right up to complete programs, can be executed on the fly without the need to compile anything. LabRPS has a built-in Python interpreter. If you don't see the window labeled Python console as shown below, you can activate it under the View → Panels → Python console.
The interpreter
From the interpreter, you can access all your system-installed Python modules, as well as the built-in LabRPS modules, and all additional LabRPS modules you installed later. The screenshot below shows the Python interpreter:
From the interpreter, you can execute Python code and browse through the available classes and functions. LabRPS provides a very handy class browser for exploration of the LabRPS world: When you type the name of a known class followed by a period (meaning you want to add something from that class), a class browser window opens, where you can navigate between available subclasses and methods. When you select something, an associated help text (if it exists) is displayed:
So, start here by typing App. or Gui. and see what happens. Another more generic Python way of exploring the content of modules and classes is to use the print(dir()) command. For example, typing print(dir()) will list all modules currently loaded in LabRPS. print(dir(App)) will show you everything inside the App module, etc.
Another useful feature of the interpreter is the possibility to go back through the command history and retrieve a line of code that you already typed earlier. To navigate through the command history, just use Up arrow or Down arrow.
By right-clicking in the interpreter window, you also have several other options, such as copy the entire history (useful when you want to experiment with things before making a full script of them), or insert a filename with complete path.
Python Help
In the LabRPS Help menu, you'll find an entry labeled Automatic python modules documentation, which will open a browser window containing a complete, realtime-generated documentation of all Python modules available to the LabRPS interpreter, including Python and LabRPS built-in modules, system-installed modules, and LabRPS additional modules. The documentation available there depends on how much effort each module developer put into documenting his code, but Python modules have a reputation for being fairly well documented. Your LabRPS window must stay open for this documentation system to work. The entry Python scripting documentation will give you a quick link to the Power users hub wiki section.
Built-in modules
Since LabRPS is designed so that it can also be run without a Graphical User Interface (GUI), almost all its functionality is separated into two groups: Core functionality, named App, and GUI functionality, named Gui. These two modules can also be accessed from scripts outside of the interpreter, by the names LabRPS and LabRPSGui respectively.
- In the
Appmodule you'll find everything related to the application itself, like methods for opening or closing files, and to the documents, like setting the active document or listing their contents.
- In the
Guimodule, you'll find tools for accessing and managing Gui elements, like the workbenches and their toolbars, and, more interestingly, the graphical representation of all LabRPS content.
Listing the content of these modules is not very useful because they grow quite fast as LabRPS develops. But the two browsing tools provided (the class browser and the Python help) should give you complete and up-to-date documentation at any moment.
The App and Gui objects
As already mentioned, in LabRPS everything is separated into core and representation. This includes the RPS Features. You can access defining properties of objects (called features in LabRPS) via the App module, and change the way they are represented on screen via the Gui module. For example, a wind velocity simulation has properties that define it (like number of process, frequency discretization, power spectral density function) that are stored in an App object, and representation properties (like whether to be shown in the tree view) that are stored in a corresponding Gui object.
This way of doing things allows a very wide range of uses, like having algorithms work only on the definition part of features, without the need to care about any visual part, or even redirect the content of the document to non-graphical application, such as lists, spreadsheets, or element analysis.
For every App object in your document, there exists a corresponding Gui object. In fact the document itself has both an App and a Gui object. This, of course, only applies when you run LabRPS with its full interface. In the command-line version no GUI exists, so only App objects are available. Note that the Gui part of objects is re-generated every time an App object is marked as 'to be recomputed' (for example when one of its parameters changes), so any changes made directly to the Gui object may be lost.
To access the App part of something, you type:
myObject = App.ActiveDocument.getObject("ObjectName")
where "ObjectName" is the name of your object. You can also type:
myObject = App.ActiveDocument.ObjectName
To access the Gui part of the same object, you type:
myViewObject = Gui.ActiveDocument.getObject("ObjectName")
where "ObjectName" is the name of your object. You can also type:
myViewObject = App.ActiveDocument.ObjectName.ViewObject
If you are in command-line mode and have no GUI, the last line will return None.
The Document objects
In LabRPS all your work resides inside documents. A document contains your simulations and can be saved to a file. Several documents can be opened at the same time. The document, has App and Gui objects. The App object contains your actual features definitions, while the Gui object contains the different views of your document. You can open several windows, each one viewing your work with a different visualization methods. These views are all part of your document's Gui object.
To access the App part of the currently open (active) document, you type:
myDocument = App.ActiveDocument
To create a new document, type:
myDocument = App.newDocument("Document Name")
To access the Gui part of the currently open (active) document, you type:
myGuiDocument = Gui.ActiveDocument
To access the current view, you type:
myView = Gui.ActiveDocument.ActiveView
Using additional modules
The LabRPS and LabRPSGui modules are only responsible for creating and managing objects in the LabRPS document. They don't actually do anything more such as creating or modifying features. This is because that feature can be of several types, and therefore requires additional modules, each responsible for managing a certain feature type. For example, the SeismicLab Workbench, is able to generate seismic ground motion by allowing the creation and the modification of SeismicLab features. Whereas the WindLab Workbench is able to build and modify random wind velocity features. In this manner LabRPS is able to handle a wide variety of object types, that can all coexist in the same document, and new types can easily be added in the future.
Creating objects
Each module has its own way of dealing with simulation, but one thing they usually all can do is create objects in the document. But the LabRPS document is also aware of the available object types provided by the modules:
LabRPS.ActiveDocument.supportedTypes()
will list all possible objects you can create. For example, let's create a part (handled by the Part module):
mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName")
The first argument is the object type, the second the name of the object.
Modifying objects
Modifying an object is done in the same way:
mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName")
mySimulation.TimeIncrement= 0.25
Querying objects
You can always look at the type of an object like this:
myObj = LabRPS.ActiveDocument.getObject("myObjectName")
print(myObj.TypeId)
or check if an object is derived from one of the basic ones (Simulation, WindLab Feature, etc):
print(myObj.isDerivedFrom("WindLab::WindLabFeature"))
Now you can really start playing with LabRPS! For a complete list of available modules and their tools, visit the Category:API section.
Power user documentation
- LabRPS scripting: Python, Introduction to Python, Python scripting tutorial, LabRPS Scripting Basics
- Modules: Units, Quantity
- Workbenches: Gui Commands, Commands
- Parametric objects: Scripted objects, Viewproviders
- Graphical interface: Interface creation, Interface creation completely in Python, PySide, PySide examples beginner, intermediate, advanced
- Macros: Macros, How to install macros
- Other: Expressions
- Hubs: User hub, Power users hub, Developer hub