LabRPS Scripting Basics: Difference between revisions

From LabRPS Documentation
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
{{Docnav
{{Docnav
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Part_scripting|Part scripting]]
|[[PySide|PySide]]
}}
}}


Line 173: Line 173:
{{Docnav
{{Docnav
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Part_scripting|Part scripting]]
|[[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:

The LabRPS 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:

The LabRPS class browser

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.

Top

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.

Top

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 App module 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 Gui module, 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.

Top

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.

Top

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

Top

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.

Top

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.

Top

Modifying objects

Modifying an object is done in the same way:

mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName")
mySimulation.TimeIncrement= 0.25

Top

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.

Top