rcenvironment / rce Goto Github PK

Under which circumstances will the "Working directory" be selected?

No matter what I choose on the wizard pages before, it´s always "Tool Directory".
Could it be, that the "Tool directory" actually refers to the temporary working directory that RCE automatically creates unless the option "do not copy" is enabled?

This is all very confusing and uses bad terminology.

Just tested the new release.
The new palette looks nice!

I'm confused, however, regarding the purpose of the custom group feature. Why is there a difference between User Integrated Tools and custom groups? And how to insert tools into these groups? I'm not able to drag'n'drop components between the trees (which would require several configuration.jsons to be modified in concert).

The dialog title states Manage ... Group assignments and Reset components to their default groups.

I assume this addition is just a preparation for a later feature not available yet? I couldn't find details in the documentation (btw - the screenshots still show the old palette).

The script element does not save changes to the script when saving. Only when repositioning the element, the script changes take effect. To reproduce this bug, follow these steps:

1. Add new script element to canvas; set to Jython
2. Edit script to print "FIRST"
3. Save workflow and execute; log says "FIRST"
4. Open script and change to print "SECOND"
5. Save workflow and execute; log says "FIRST"
6. Move position of script element on canvas
7. Save workflow and execute; log says "SECOND"

I recently started using the program. I have a simple workflow with an input, a script and another script to print the result (it's just a test because a parametric study didn't work because of the problem I am describing).

The script that I use in written in Python and it basicly writes the input in a xml file, witch is the input of an executable that does some calculations and writes the result in a .txt .

The result seems to be correct, but it doesn't pass it as an output to the next script using RCE.write_output ("output0", output_result) . All inputs and outputs are correctly declared and the components are connected. Is it maybe a problem of my executable?

Thank you.

However, it is marked as "error" while it should be just a warning.
Had this message again today after first time yesterday.
Anyway I fail to reproduce it right now. Restarting RCE, reopening the workflow, choosing a different executable, all doesn't help to reproduce it.

Python 3.12 is missing the "imp" module which leads to an error when using it within RCE:

Hi,
we are using rcenvironment / rce at iwes.uni-hannover.de. I just scanned the files of version 10.2.4 and found dependencies on log4j 1.10.3. E.g. in rce-10.2.4.202108191008-standard-win32.x86_64\rce\plugins\org.apache.ant_1.10.3.v20180417-1627\META-INF\maven\org.eclipse.orbit.bundles\org.apache.ant

Do you have any recommendations or updates? log4j version 1 is not affected by the bug but it is not recommended for use because of other security flaws (in german: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html )

Best regards,
Stefan Warnken

I'm not sure if these files belong into the release ZIP, they look like timestamped backups?

I think this is a repost (from Mantis bug tracker times?), but I couldn't find a definite answer.

When updating components.json programmatically, RCE doesn't get notified (on Windows).
Only a restart of the running instance will pick up newly published tools.
I vaguely remember "this should work usually" with some caveats - can you give an assessment?

Is there an API (right now, not in future versions) to trigger the update and re-populatoin of the tool list?

E.g. tool integration wizard Text/Bool/Int/...Dir
vs. script and input provider (alphabetic)

Couldn't find the matching resource property in https://github.com/rcenvironment/rce/blob/master/main/de.rcenvironment.core.gui.wizards.toolintegration/src/main/java/de/rcenvironment/core/gui/wizards/toolintegration/messages.properties

In the tool integration wizard the characters in the Command for Windows/Command for Linux_ in the execution tab are not rendered properly. This problem does not occur on the other tabs. The problem is observed in RCE10.2 & RCE10.3 on Ubuntu 20.04.

See screenshot below.

On each RCE start, the first editor tab is selected again, making it harder to see where one was working at when closing RCE. As all tabs and their order is persisted fine, this is the only missing piece.

What steps will reproduce the problem?

1. Running provided workflow on protec.kp.dlr.de
2. The workflow runs fine if connection between input provider and cluster is removed

What is the expected output? What do you see instead?
java.lang.NullPointerException. See below.

What version of the product are you using? On what operating system?
Version: 6.3.0 on openSUSE 11.4 (x86_64)

Please provide any additional information below.

Error message in log:
Workflow 'cluster_bug_2015-08-17_09:56:51_15' (bfda5b5b-9e5b-458e-8225-1ef34955d84a) will be cancelled as a component failed

java.lang.NullPointerException
at de.rcenvironment.components.cluster.execution.ClusterComponent.processInputs(ClusterComponent.java:191)
at de.rcenvironment.core.component.execution.internal.ComponentExecutionControllerImpl$ComponentStateMachine$AsyncProcessInputsTask$1.execute(ComponentExecutionControllerImpl.java:1184)
at de.rcenvironment.core.component.execution.internal.ComponentExecutionControllerImpl$ComponentExecuter.executeByConsideringLimitations(ComponentExecutionControllerImpl.java:1519)
at de.rcenvironment.core.component.execution.internal.ComponentExecutionControllerImpl$ComponentStateMachine$AsyncProcessInputsTask.run(ComponentExecutionControllerImpl.java:1186)
at de.rcenvironment.core.utils.common.concurrent.SharedThreadPool$WrappedRunnable.run(SharedThreadPool.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Note: Originally submitted by markus.schnoes via Google Code

Dear RCE-Team,

I have a question to the python configuration in RCE. I would like to define my own sampling via Python script which provides a matrix:

with:

from SALib.sample import saltelli

problem = {'num_vars': 2,
           'names' : ['var1','var2'],
           'bounds' : [[-1., 1.,],
                      [-1.5, 1.5]]}

samples = saltelli.sample(problem, 100)
RCE.write_output("Samples",samples.tolist())

I configured python (using a Conda environment) via:

	"thirdPartyIntegration": {
			"python":{
			"binaryPath": "D:/Programme/Miniconda3/envs/python3_cpacs/python.exe"
					}
			}

Usually these scripts are running without problems. However, when I load a module which uses Numpy (such as SALib in the above example) the following error occurs:

2021-04-26-14:18:47,127 TOOL ERROR: D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\__init__.py:143: UserWarning: mkl-service package failed to import, therefore Intel(R) MKL initialization ensuring its correct out-of-the box operation under condition when Gnu OpenMP had already been loaded by Python process is not assured. Please install mkl-service package, see http://github.com/IntelPython/mkl-service
2021-04-26-14:18:47,127 TOOL ERROR:   from . import _distributor_init
2021-04-26-14:18:47,147 TOOL ERROR: Traceback (most recent call last):
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\core\__init__.py", line 22, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:     from . import multiarray
2021-04-26-14:18:47,147 TOOL ERROR:   File "C:\Users\alde_ma\AppData\Local\Temp\rce-temp\default-1619437204945\424-pythonAgent/RCE_PythonClient.py", line 147, in executeUserscriptJSON
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\core\multiarray.py", line 12, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:     exec(codeObject, CONTEXT)
2021-04-26-14:18:47,147 TOOL ERROR:     from . import overrides
2021-04-26-14:18:47,147 TOOL ERROR:   File "script", line 1, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\core\overrides.py", line 7, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\SALib\sample\saltelli.py", line 3, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:     from numpy.core._multiarray_umath import (
2021-04-26-14:18:47,147 TOOL ERROR:     import numpy as np
2021-04-26-14:18:47,147 TOOL ERROR: ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\__init__.py", line 145, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:     from . import core
2021-04-26-14:18:47,147 TOOL ERROR: During handling of the above exception, another exception occurred:
2021-04-26-14:18:47,147 TOOL ERROR:   File "D:\Programme\Miniconda3\envs\python3_cpacs\lib\site-packages\numpy\core\__init__.py", line 48, in <module>
2021-04-26-14:18:47,147 TOOL ERROR:     raise ImportError(msg)
2021-04-26-14:18:47,147 TOOL ERROR: Traceback (most recent call last):
2021-04-26-14:18:47,147 TOOL ERROR: ImportError: 
2021-04-26-14:18:47,147 TOOL ERROR: IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
2021-04-26-14:18:47,147 TOOL ERROR: Importing the numpy C-extensions failed. This error can happen for
2021-04-26-14:18:47,147 TOOL ERROR: many reasons, often due to issues with your setup or how NumPy was
2021-04-26-14:18:47,147 TOOL ERROR: installed.
2021-04-26-14:18:47,147 TOOL ERROR: We have compiled some common reasons and troubleshooting tips at:
2021-04-26-14:18:47,147 TOOL ERROR:     https://numpy.org/devdocs/user/troubleshooting-importerror.html
2021-04-26-14:18:47,147 TOOL ERROR: Please note and check the following:
2021-04-26-14:18:47,147 TOOL ERROR:   * The Python version is: Python3.7 from "D:\Programme\Miniconda3\envs\python3_cpacs\python.exe"
2021-04-26-14:18:47,147 TOOL ERROR:   * The NumPy version is: "1.20.1"
2021-04-26-14:18:47,147 TOOL ERROR: and make sure that they are the versions you expect.
2021-04-26-14:18:47,147 TOOL ERROR: Please carefully study the documentation linked above for further help.
2021-04-26-14:18:47,147 TOOL ERROR: Original error was: DLL load failed: Das angegebene Modul wurde nicht gefunden.
2021-04-26-14:18:47,155 COMPONENT ERROR: Failed to execute script. (E#1619439527218)
[Log file format version: 1.0]

In my Conda environment itself, Numpy loads without problems and the example above runs without errors. I have observed a similar error when I have included my own python tool. Here I could work around the error by specifying the Python path via the execution command:

set PATH=D:\Programme\Miniconda3\envs\python3_cpacs\Scripts;D:\Programme\Miniconda3\envs\python3_cpacs;%PATH
D:\Programme\Miniconda3\condabin\activate.bat python3_cpacs
python run.py

In the configuration file under thirdPartyIntegration only the binaryPath can be specified, right?

Thanks for your help!

I just discovered the option to create a configuration right from an existing connection! Super neat!

However there is one problem with the example configurations: They contain // comments, which are outside the JSON spec and make the files invalid. JSON parsers should treat // as an error (but some ignore it, out of spec).

One workaround is using same-line key-values like "_comment": "Here goes the comment", but processing JSON maps in code may lead to reordering of keys anyway, and eliding duplicate keys as well, so that comments get lost or mixed. JSON is just not a format that is able to keep metadata.

One of our colleagues is creating MDO architectures in RCE workflows and encountered some problems after migrating workflows from 7.0 to 8.0

• Workflow graph error (driver-related):

  2017-04-12-13:12:29,800 WORKFLOW ERROR: Wokflow logic invalid; cause: Error in workflow graph search: newly determined driver node differs from driver node determined earlier (E#1491995549800)
  [Log file format version: 1.1]
  
  E#1491995549800: Workflow 'mdo_BLISS_Sellar_2017-04-12_13:12:24_47' (9259b587-a8c0-4839-8a82-be6012c0ef96) failed and will be cancelled:
  

• inner loop channel inputs:

  2017-04-12-13:24:09,267 COMPONENT ERROR - Disc2_D2: A second value at input 'y1c' of type 'constant' received. Only one value is allowed. First: '0.0' (633efc47-a0a4-4875-86f1-143a91ead47a @ "Default instance started by "torr_fr-a" on LY-320124" [f3c8635d20479bf3079a1510854971a4:0] -> y1c @ Disc2_D2 (1122b98b-482c-4705-8998-bb54f874b265) at "Default instance started by "torr_fr-a" on LY-320124" [f3c8635d20479bf3079a1510854971a4:0]). Second: '0.0' (633efc47-a0a4-4875-86f1-143a91ead47a @ "Default instance started by "torr_fr-a" on LY-320124" [f3c8635d20479bf3079a1510854971a4:0] -> y1c @ Disc2_D2 (1122b98b-482c-4705-8998-bb54f874b265) at "Default instance started by "torr_fr-a" on LY-320124" [f3c8635d20479bf3079a1510854971a4:0]). (Except in inner loops. There, one value is allowed for each inner loop run.) (E#1491996249267)
  

First issue only came up after migrating to 8.0, but did work fine earlier.

The second issue has a tool input value in a inner loop set to constant, which is assumed to be updated on every change in the outer loop (he says it did work in 7.0, but no longer in 8.0). Is this behaviour of nested loops and driver components documented somewhere?

The user guide mentions as a prerequisite https://www.java.com/de/download/ but you could probably describe more generally a JRE 64bit 8 or higher with a few options to optain one from (e.g. Eclipse Adoptium).

Sometimes, when I start a workflow with components from a remote (vm, through vpn), the above error occurs and the workflow fails. The error then appears all the time I try to run workflow.

• The connection seems to be stable otherwise (no disconnections or anything noticable).
• Tools are visible in User Integrated Tools all the time.
• Restarting the vm helped once, now it doesn't help anymore.
• Restarting RCE, either vm or locally, doesn't help.
• There is enough hard disc space on the vm
• RCE 10.3.1 used on both machines

I want to do the following:
I have an RCE instance running on Machine A (Linux), where some components are published. I want to run a workflow that executes one of the components, but need to call it via console (inside a script that I have), so what I call is (for testing if everythin is set up corectly):

rce.exe -p default --headless --exec "components list -r ; stop"
or
rce.exe -p default --batch "components list -r

and get the following Message:

Failed to connect to "129.247.149.169:21000": Ignoring a request to connect to 129.247.149.169:21000 (activemq-tcp) as the network layer is shutting down (Connection details: activemq-tcp:129.247.149.169:21000(connectOnStartup=true, autoRetryDelayMultiplier=1.5, autoRetryInitialDelay=5, autoRetryMaximumDelay=300, autoRetry=true))

If I open the console with rce.exe --headless -console and type the commands rce components list -r, everything runs as expected.

Starting a local RCE instance in advance and then connecting to it via "ssh wfadmin@localhost" could be an option, but would make it one more "manual" step, which we do not want to have in our approach.

I attached the corresponding log file:
debug.log

Many recent papers claim RCE's capability to parse CMDOWS file into an executable workflow, e.g. https://link.springer.com/article/10.1007/s13272-018-0307-2. I also have found that this was actually done according to bugtracker https://mantis.sc.dlr.de/view.php?id=15191 and changlog on mantis.cs.dlr.de. However I couldn't find a way to do this in latest RCE. Is this functionality closed for public use in RCE or there is some non-obvious way to do this?

I cannot find any information on the command line tool for SSH access to remote RCEs.

During my installation process, I came across the following error:

error: Failed dependencies:
        libgfortran.so.3()(64bit) is needed by rce-10.3.0.202112090919-standard.x86_64

It seems that most modern Linux desktop systems do not support libgfortran3 anymore. Please consider updating the dependency.

The link to your new website seems to be
http://dlr-sc.github.io/rce-website/
as opposed to the one advertised in the readme. Maybe you want to update the redirect from http://rcenvironment.de ? (Currently still pointing me to https://code.google.com/a/eclipselabs.org/p/rce/ )

When a Tool writes Logs to the Console with logging, the logging level (in this case "INFO") is not preserved through RCE.
It instead gives a "WARN" message.
It then looks like this:

2019-12-02 10:57:25,873 WARN  - de.rcenvironment.core.component.execution.api.ConsoleRowUtils - INFO     __main__

This is especially confusing, since in the workflow console those messages appear in read, even though nothing went wrong in the tool.

Is this intended behavior? If so, it should be noted somewhere and I should use "DEBUG" instead of "INFO" for my logging levels for the RCE.

I tested it with RCE 10.0, my scripts are running python 3.7 using the logging module

Seems like there is a limit to cloning LFS items:

D:\forks\_old dlr>git clone https://github.com/rcenvironment/rce.git
Cloning into 'rce'...
remote: Enumerating objects: 82881, done.
remote: Counting objects: 100% (16930/16930), done.
remote: Compressing objects: 100% (6359/6359), done.
remote: Total 82881 (delta 7509), reused 13932 (delta 5760), pack-reused 65951
Receiving objects: 100% (82881/82881), 111.61 MiB | 952.00 KiB/s, done.
Resolving deltas: 100% (41213/41213), done.
Updating files: 100% (6175/6175), done.
Downloading de.rcenvironment.binaries.dakota.linux.x86_64/resources/binaries-lfs/dakota (38 MB)
Error downloading object: de.rcenvironment.binaries.dakota.linux.x86_64/resources/binaries-lfs/dakota (1a626f7): Smudge error: Error downloading de.rcenvironment.binaries.dakota.linux.x86_64/resources/binaries-lfs/dakota (1a626f77d05837d3de2cb8a12757d91b835e2d5f5b214539f3550d006921978d): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

Errors logged to D:\forks\_old dlr\rce\.git\lfs\logs\20210420T092503.230755.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: de.rcenvironment.binaries.dakota.linux.x86_64/resources/binaries-lfs/dakota: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

FYI

RCE 10.5.0

Maybe no available Windows handles?

I could not reproduce.

Just a heads-up from an internal user that my test suite broke recently, as the VERSION files for old RCE versions (e.g. 6.2.1) were removed from the archive. Can you confirm and close this issue please?

I've created some tools in python and integrated them in RCE. The tools seem to work when run individuaally, but RCE hangs when the tools are integrated. I've tried giving the output of the preceeding tool as the input to the succeeding tool when I run them alone and it seems to work too. However, integrating them in a single workflow makes RCE hang.

RCE Version - 7.1.4, 32 Bit (64 Bit doesn't work)

OS - Windows 8.1 , 64 Bit

If I open just one RCE instance on the network for remote access, but want to publish a tool on a different RCE behind it, there is currently no option for that.
I don´t want to open (and manage) a SSH port for each instance that I potentially want to publish a workflow on.

I.e. sysmon has both options already, local and remote.

The alignment settings in the properties tab of the label object only affects where the text is arranged within the label box but does not change the text alignment itself.
It would be good to e.g. also have center aligned text if center alignment is selected in the label properties. Currently the text stays left-justified but is moved to the center of the box.

I have reported several issues, but there´s no activity whatsoever. The project appears dead to the outside user. There should be discussion on gitter, and also in the issues here, probably some gists...

In issue #484 we plan to exclude the toolspecifics from CPACS. This is realized by the xsd:any element with processContents=strict attribute, i.e. the XML processor must obtain the schema for the required namespaces for a proper validation of the XML files. The tool owners must provide this schema file.

The integration of a CPACS tool in RCE provides the possibility to add a documentation file. The same way tool integrators need a possibility to attach the corresponding schema file. This would enable users can run proper validation.

When using wrong connection details (server, port)
the following dialog pops up.
üImage+(http://www.imgpaste.net/image/u4lKs)

Any idea why those components are cancelled and don't run?
I think it worked once, but have no idea what is wrong, there is no information in RCE that shows the source of the error, nor any tool output (the "Run" node is entirely missing).
One older message is "no tool output mapping" or so, hinting to tool not having been executed, but how would that affect later runs?

2018-03-08 11:12:00,792 DEBUG - de.rcenvironment.toolkit.modules.statistics.internal.StatisticsTrackerServiceImpl - Returning a disabled receiver for category 'AsyncOrderedExecutionQueue elements dispatched' as it was requested with level DEVELOPMENT while the global level is RELEASE
2018-03-08 11:12:00,792 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'Tornado_wdev' (d9286ea1-0579-4388-aeb0-f6a9dedd864f) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now TEARING_DOWN (previous state: CANCELLING)
2018-03-08 11:12:02,990 DEBUG - de.rcenvironment.toolkit.modules.statistics.internal.StatisticsTrackerServiceImpl - Returning a disabled receiver for category 'AsyncOrderedExecutionQueue elements dispatched' as it was requested with level DEVELOPMENT while the global level is RELEASE
2018-03-08 11:12:02,990 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'FuCD_w_dev' (50d39f3e-56c8-4146-b49f-d8b4196d6133) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now TEARING_DOWN (previous state: CANCELLING)
2018-03-08 11:12:03,179 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'FuCD_w_dev' (50d39f3e-56c8-4146-b49f-d8b4196d6133) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now CANCELED (previous state: TEARING_DOWN)
2018-03-08 11:12:03,199 DEBUG - de.rcenvironment.core.component - ServiceEvent UNREGISTERING - {de.rcenvironment.core.component.execution.api.ComponentExecutionController}={rce.component.execution.id=50d39f3e-56c8-4146-b49f-d8b4196d6133, service.id=717} - de.rcenvironment.core.component
2018-03-08 11:12:03,200 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'FuCD_w_dev' (50d39f3e-56c8-4146-b49f-d8b4196d6133) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now DISPOSING (previous state: CANCELED)
2018-03-08 11:12:03,212 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'FuCD_w_dev' (50d39f3e-56c8-4146-b49f-d8b4196d6133) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now DISPOSED (previous state: DISPOSING)
2018-03-08 11:12:03,293 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'Tornado_wdev' (d9286ea1-0579-4388-aeb0-f6a9dedd864f) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now CANCELED (previous state: TEARING_DOWN)
2018-03-08 11:12:03,304 DEBUG - de.rcenvironment.core.component - ServiceEvent UNREGISTERING - {de.rcenvironment.core.component.execution.api.ComponentExecutionController}={rce.component.execution.id=d9286ea1-0579-4388-aeb0-f6a9dedd864f, service.id=718} - de.rcenvironment.core.component
2018-03-08 11:12:03,305 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'Tornado_wdev' (d9286ea1-0579-4388-aeb0-f6a9dedd864f) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now DISPOSING (previous state: CANCELED)
2018-03-08 11:12:03,317 DEBUG - de.rcenvironment.core.component.execution.internal.ComponentStateMachine - Component 'Tornado_wdev' (d9286ea1-0579-4388-aeb0-f6a9dedd864f) of workflow 'l;+l;+;l+;l' (7d89fa54-6667-4eaa-bdf3-a48aedff181f) is now DISPOSED (previous state: DISPOSING)

Currently the integrated jython runs V2.5.1 which, e.g., doesn't support str.format() function.

Looking at https://github.com/rcenvironment/rce/tree/master/de.rcenvironment.binaries.tiglviewer.win32.x86_64/resources/binaries, I see the following binary files:

• Qt DLLs
• TIGL DLLs
• some Visual Studio redistributable DLLs
• TBB DLLs
• Other stuff (?)

At least for Qt I can point you to an FAQ entry (point 3.7 under https://www.qt.io/faq/). I am assuming that you do not have a commercial Qt license. I cannot copy&paste from that page, but the second bullet point basically says that you have to also distribute the source code of Qt (and that just providing a link to "upstream" is not enough).

(While we are at it: You might also double check the last bullet point which requires a prominent notice)

Disclaimer: IANAL

The input provider with the directory output variable has a grayed out stop symbol for one more minute until stopping (marked failed).

When I run the build the default product launch file, appeared in the process of compiling can't find org.apache.com mons. Logging 1.1.1 errors

error stack is

[INFO] --- exec-maven-plugin:1.3.2:java (default) @ de.rcenvironment.maven.preprocessor ---
[INFO] Scanning for projects...
[INFO] Computing target platform for MavenProject: de.rcenvironment:de.rcenvironment.core.authentication:10.1.1-SNAPSHOT @ E:\workspace\rce-10.1.1-release-source\de.rcenvironment.core.authentication\pom.xml
[INFO] Resolving dependencies of MavenProject: de.rcenvironment:de.rcenvironment.core.authentication:10.1.1-SNAPSHOT @ E:\workspace\rce-10.1.1-release-source\de.rcenvironment.core.authentication\pom.xml
[INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true, osgi.arch=x86_64}
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: de.rcenvironment.core.authentication 10.1.1.qualifier
[ERROR] Missing requirement: de.rcenvironment.core.authentication 10.1.1.qualifier requires 'java.package; org.apache.commons.logging 1.1.1' but it could not be found
[ERROR]
[ERROR] See http://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
[ERROR] Cannot resolve dependencies of MavenProject: de.rcenvironment:de.rcenvironment.core.authentication:10.1.1-SNAPSHOT @ E:\workspace\rce-10.1.1-release-source\de.rcenvironment.core.authentication\pom.xml: See log for details -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException

I integrated a tool with this path: My/Group/Path//My/Second/Group which creates an empty folder in the palette :-D

Also:

Just some food for though...

• The abbreviation RCE is often seen in security advisories for remote code execution, which has a negative connotation
• RCE as a three-letter abbreviation is prone to be used in many other areas and might lead to wrong hits in search engines
• rcenvironment.de as a URL is a bit clearer, but mixes abbreviation for "RC" and a full word "environment", which always seemed odd and distracting to me
• targeting an international audience, I'm not sure if .de is the best suited TLD, but it can be considered trust-worthy and matches DLR's origin, so no complaints here

Expose the channel semantics through the webservice and add security (e.g. configured in the run time dialog for these server instances)

Triggering the export of data while previously initiated data is still exporting, the first export process seems to be cancled. At least the data will not be exported completely.
Also the message shown when the export is finished shows the second name for both export tasks.
I'll try and describe it a bit mor structured:

1. Initiate export of Data from 'Tool Run 1'
2. The export screen shows exporting of 'Tool Run 1'
3. Before the export is finished I start another export of 'Tool Run 2'
4. Very quickly I get the successful export method for 'Tool Run 2'
5. Later I get another successful export message again for 'Tool Run 2'
6. When I check the data for 'Tool Run 1' I can see that it was not completely exported.

The output of the converger component is completely different between the converged and not converged state, which makes it difficult to trigger logic depending on this condition: for example, "done:", "converged", "converged relative" and "converged absolute" are only written once convergence is reached, while "_is_converged:false" is only written when it is not converged, and then becomes "_converged:value".

If I want to save the output of a component inside the convergence loop only if that iteration led to a converged state, I cannot use a switch triggered by the converger because the number of values sent to the switch will never match the number of iterations.

Writing "Converged:false" while convergence is not reached would be enough to solve the problem, although If there is a workaround I haven't thought of I'd be thankful for any idea

Complete path length incl filename is limited. 142/141 character are marked red.

Limit seems to be independent from OperatingSystem (Win + Linux).