LabRPS Scripting Basics - Revision history

LabRPS at 03:18, 30 October 2024

2024-10-30T03:18:54Z

← Older revision		Revision as of 20:18, 29 October 2024
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]]
	}}		}}

LabRPS at 03:11, 30 October 2024

2024-10-30T03:11:55Z

← Older revision		Revision as of 20:11, 29 October 2024
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 ~~scene~~ contents~~, and even the representation of this content in the 3D views~~, 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.		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 ~~3D objects~~. 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 ~~cube~~ has properties that define it (like ~~width~~, ~~length~~, ~~height~~) that are stored in an {{incode\|App}} object, and representation properties (like ~~faces color, drawing mode~~) that are stored in a corresponding {{incode\|Gui}} object.		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 ~~geometry~~ and can be saved to a file. Several documents can be opened at the same time. The document, ~~like the geometry contained inside,~~ has {{incode\|App}} and {{incode\|Gui}} objects. The {{incode\|App}} object contains your actual ~~geometry~~ 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 ~~zoom factor or from a different direction~~. These views are all part of your document's {{incode\|Gui}} object.		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 [[~~Part_Workbench~~\|~~Part~~ Workbench]]~~, using the OpenCascade kernel~~, is able to ~~create~~ and ~~manipulate [http://en.wikipedia.org/wiki/Boundary_representation BRep] type feature (geometry)~~. 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.		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=
	~~myPart~~ = LabRPS.ActiveDocument.addObject("~~Part~~::~~Feature~~", "~~myPartName~~")		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.

	~~{{Code\|code=~~
	~~import Part~~
	~~cube = Part.makeBox(2, 2, 2)~~
	~~myPart.Shape = cube~~
	}}

	{{Top}}		{{Top}}
Line 150:		Line 144:

	{{Code\|code=		{{Code\|code=
	~~import Part~~		mySimulation= LabRPS.ActiveDocument.addObject("WindLab::WindLabSimulation", "mySimulationName")
	~~cube~~ = ~~Part~~.~~makeBox~~(2, ~~2, 2~~)		mySimulation.TimeIncrement= 0.25
	~~myPart~~.~~Shape~~ = ~~cube~~
	}}

	~~Now let's change the shape by a bigger one:~~

	~~{{Code\|code=~~
	~~biggercube = Part.makeBox(5, 5, 5)~~
	~~myPart~~.~~Shape = biggercube~~
	}}		}}

Line 174:		Line 160:


	or check if an object is derived from one of the basic ones (~~Part Feature~~, WindLab Feature, etc):		or check if an object is derived from one of the basic ones (Simulation, WindLab Feature, etc):

	{{Code\|code=		{{Code\|code=
	print(myObj.isDerivedFrom("~~Part~~::~~Feature~~"))		print(myObj.isDerivedFrom("WindLab::WindLabFeature"))
	}}		}}

LabRPS: /* The interpreter */

2024-07-27T16:07:00Z

The interpreter

← Older revision		Revision as of 09:07, 27 July 2024
Line 16:		Line 16:
	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 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:

	[[Image:screenshot_pythoninterpreter.~~jpg~~\|The LabRPS Python interpreter]]		[[Image:screenshot_pythoninterpreter.png\|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:		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:

	[[Image:screenshot_classbrowser.~~jpg~~\|The LabRPS class browser]]		[[Image:screenshot_classbrowser.png\|The LabRPS class browser]]

	So, start here by typing {{incode\|App.}} or {{incode\|Gui.}} and see what happens. Another more generic Python way of exploring the content of modules and classes is to use the {{incode\|print(dir())}} command. For example, typing {{incode\|print(dir())}} will list all modules currently loaded in LabRPS. {{incode\|print(dir(App))}} will show you everything inside the App module, etc.		So, start here by typing {{incode\|App.}} or {{incode\|Gui.}} and see what happens. Another more generic Python way of exploring the content of modules and classes is to use the {{incode\|print(dir())}} command. For example, typing {{incode\|print(dir())}} will list all modules currently loaded in LabRPS. {{incode\|print(dir(App))}} will show you everything inside the App module, etc.

LabRPS: Created page with "{{Docnav |Python scripting tutorial |Part scripting }} {{TOCright}} ==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 scene contents, and even the representation of this content in the 3D views, are accessible from the built-in Python interpreter or from your own scripts. As a result, LabRPS is probably one of t..."

2024-07-27T15:52:23Z

Created page with "{{Docnav |Python scripting tutorial |Part scripting }} {{TOCright}} ==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 scene contents, and even the representation of this content in the 3D views, are accessible from the built-in Python interpreter or from your own scripts. As a result, LabRPS is probably one of t..."

New page

{{Docnav
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Part_scripting|Part scripting]]
}}

{{TOCright}}

==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 scene contents, and even the representation of this content in the 3D views, 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}}.

===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:

[[Image:screenshot_pythoninterpreter.jpg|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:

[[Image:screenshot_classbrowser.jpg|The LabRPS class browser]]

So, start here by typing {{incode|App.}} or {{incode|Gui.}} and see what happens. Another more generic Python way of exploring the content of modules and classes is to use the {{incode|print(dir())}} command. For example, typing {{incode|print(dir())}} will list all modules currently loaded in LabRPS. {{incode|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 {{KEY|Up arrow}} or {{KEY|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 {{MenuCommand|Help}} menu, you'll find an entry labeled {{MenuCommand|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 {{MenuCommand|Python scripting documentation}} will give you a quick link to the [[Power_users_hub|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 {{incode|App}}, and GUI functionality, named {{incode|Gui}}. These two modules can also be accessed from scripts outside of the interpreter, by the names {{incode|LabRPS}} and {{incode|LabRPSGui}} respectively.

* In the {{incode|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 {{incode|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 3D objects. 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 cube has properties that define it (like width, length, height) that are stored in an {{incode|App}} object, and representation properties (like faces color, drawing mode) 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.

For every {{incode|App}} object in your document, there exists a corresponding {{incode|Gui}} object. In fact the document itself has both an {{incode|App}} and a {{incode|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 {{incode|App}} objects are available. Note that the {{incode|Gui}} part of objects is re-generated every time an {{incode|App}} object is marked as 'to be recomputed' (for example when one of its parameters changes), so any changes made directly to the {{incode|Gui}} object may be lost.

To access the {{incode|App}} part of something, you type:

{{Code|code=
myObject = App.ActiveDocument.getObject("ObjectName")
}}

where {{incode|"ObjectName"}} is the name of your object. You can also type:

{{Code|code=
myObject = App.ActiveDocument.ObjectName
}}

To access the {{incode|Gui}} part of the same object, you type:

{{Code|code=
myViewObject = Gui.ActiveDocument.getObject("ObjectName")
}}

where {{incode|"ObjectName"}} is the name of your object. You can also type:

{{Code|code=
myViewObject = App.ActiveDocument.ObjectName.ViewObject
}}

If you are in command-line mode and have no GUI, the last line will return {{incode|None}}.

{{Top}}

===The Document objects===

In LabRPS all your work resides inside documents. A document contains your geometry and can be saved to a file. Several documents can be opened at the same time. The document, like the geometry contained inside, has {{incode|App}} and {{incode|Gui}} objects. The {{incode|App}} object contains your actual geometry 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 zoom factor or from a different direction. 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:

{{Code|code=
myDocument = App.ActiveDocument
}}

To create a new document, type:

{{Code|code=
myDocument = App.newDocument("Document Name")
}}

To access the {{incode|Gui}} part of the currently open (active) document, you type:

{{Code|code=
myGuiDocument = Gui.ActiveDocument
}}

To access the current view, you type:

{{Code|code=
myView = Gui.ActiveDocument.ActiveView
}}

{{Top}}

==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 [[Part_Workbench|Part Workbench]], using the OpenCascade kernel, is able to create and manipulate [http://en.wikipedia.org/wiki/Boundary_representation BRep] type feature (geometry). 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}}

===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:

{{Code|code=
LabRPS.ActiveDocument.supportedTypes()
}}

will list all possible objects you can create. For example, let's create a part (handled by the {{incode|Part}} module):

{{Code|code=
myPart = LabRPS.ActiveDocument.addObject("Part::Feature", "myPartName")
}}

The first argument is the object type, the second the name of the object.

{{Code|code=
import Part
cube = Part.makeBox(2, 2, 2)
myPart.Shape = cube
}}

{{Top}}

===Modifying objects===

Modifying an object is done in the same way:

{{Code|code=
import Part
cube = Part.makeBox(2, 2, 2)
myPart.Shape = cube
}}

Now let's change the shape by a bigger one:

{{Code|code=
biggercube = Part.makeBox(5, 5, 5)
myPart.Shape = biggercube
}}

{{Top}}

===Querying objects===

You can always look at the type of an object like this:

{{Code|code=
myObj = LabRPS.ActiveDocument.getObject("myObjectName")
print(myObj.TypeId)
}}

or check if an object is derived from one of the basic ones (Part Feature, WindLab Feature, etc):

{{Code|code=
print(myObj.isDerivedFrom("Part::Feature"))
}}

Now you can really start playing with LabRPS! For a complete list of available modules and their tools, visit the [[:Category:API|Category:API]] section.

{{Top}}

{{Docnav
|[[Python_scripting_tutorial|Python scripting tutorial]]
|[[Part_scripting|Part scripting]]
}}

{{Powerdocnavi}}
[[Category:Developer Documentation]]
[[Category:Python Code]]