Add new FMU node-type by riteshk001 · Pull Request #1017 · VILLASframework/node

riteshk001 · 2026-06-17T12:22:36Z

New node type implementation based on Functional Mock-up Interface (FMI 3.0). Currently supports Co-Simulation. Functionality can be further extended to include Model Exchange simulation too.

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com>

stv0g

Nice work. Its great to see FMI support landing in VILLAS

stv0g · 2026-07-09T14:46:45Z

+  while (hasInputs && (writingTurn || currentTime >= stopTime)) {
+    pthread_cond_wait(&cv, &mutex);
+  }
+  double targetTime = currentTime + stepSize;


I think this not executing the FMU using a real-time scale?

Can you elaborate a bit how this node-type is indentend to be used?
E.g. does it expect periodic input data to proceed its internal time?
How does the internal time related to the real time?

Do we already have a PR for the node-type? I think this deserves some explanation.

Right now, it needs periodic input data. My plan would be to include real-time later

Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

pjungkamp

I really like the general coding style, it's clean and very readable. Could you please fix the commit such that you have one commit that introduces the FMU node type. You have two unrelated changes changing the capitalization of writing_turn in opendss.{hpp,cpp} which should not be part of that commit. You can either move those changes into their commit or drop them.

pjungkamp · 2026-07-29T07:17:26Z

+      description: |
+        Specifies the URI to a directory which has the unpacked files of the FMU model (mainly the shared library and the modelDescription.xml for the model).
+
+    fmuWritefirst:


Suggested change

fmuWritefirst:

fmu_write_first:

pjungkamp · 2026-07-29T07:17:40Z

+      description: |
+        Specifies whether the model has to be writtem with input values before running. `true` denotes that the model should use the input values. `false` would make the model use default values instead.
+
+    startTime:


Suggested change

startTime:

start_time:

pjungkamp · 2026-07-29T07:17:50Z

+      description: |
+        Specifies the start time for the simulation. Value has to be at least one `stepSize` lesser than `stopTime`.
+
+    stopTime:


Suggested change

stopTime:

stop_time:

pjungkamp · 2026-07-29T07:18:01Z

+      description: |
+        Specifies the stop time for the simulation. The number of steps is calculated then by the difference between `startTime` and `stopTime` divided by the `stepSize`.
+
+    stepSize:


Suggested change

stepSize:

step_size:

pjungkamp · 2026-07-29T07:24:01Z

+    file_output = {
+        type = "file"
+        # format = "csv"
+        uri = "/workspaces/node/fmu_temp/output.dat"
+    },
+
+    signal_node = {
+        type = "signal.v2"
+        rate = 100.0
+        realtime = true
+
+        limit = 100
+
+        in = {
+            signals = (
+                { name = "sine1",   signal = "sine",   amplitude = 1, frequency = 100   },
+                # { name = "in2",   signal = "constant", amplitude = 1  },
+            )
+        }
+    },


Suggested change

file_output = {

type = "file"

# format = "csv"

uri = "/workspaces/node/fmu_temp/output.dat"

},

signal_node = {

type = "signal.v2"

rate = 100.0

realtime = true

limit = 100

in = {

signals = (

{ name = "sine1", signal = "sine", amplitude = 1, frequency = 100 },

# { name = "in2", signal = "constant", amplitude = 1 },

)

}

},

The example configuration file is embedded into the documentation and should only contain the node that this example is for. Runnable examples aren't part of this repo.

pjungkamp · 2026-07-29T07:31:26Z

+
+public:
+  FmuNode(const uuid_t &id = {}, const std::string &name = "");
+  struct fmu_signal {


Types/classes defined in villas-node are PascalCase. Rename fmu_signal to FmuSignal and move it outside the FmuNode.

pjungkamp · 2026-07-29T07:37:41Z

+  ret = json_unpack_ex(
+      json, &err, 0, "{s:s, s:s, s?:f, s?:f, s?:f, s?:{s:o}, s?:{s:o}}",
+      "fmu_path", &path, "fmu_unpack_path", &unpack_path, "stopTime", &stopTime,
+      "startTime", &startTime, "stepSize", &stepSize, "in", "signals",
+      &json_signals_in, "out", "signals", &json_signals_out);


Suggested change

ret = json_unpack_ex(

json, &err, 0, "{s:s, s:s, s?:f, s?:f, s?:f, s?:{s:o}, s?:{s:o}}",

"fmu_path", &path, "fmu_unpack_path", &unpack_path, "stopTime", &stopTime,

"startTime", &startTime, "stepSize", &stepSize, "in", "signals",

&json_signals_in, "out", "signals", &json_signals_out);

ret = json_unpack_ex(

json, &err, 0, "{s:s, s:s, s?:f, s?:f, s?:f, s?:{s:o}, s?:{s:o}}",

"fmu_path", &path, "fmu_unpack_path", &unpack_path, "stop_time", &stopTime,

"start_time", &startTime, "step_size", &stepSize, "in", "signals",

&json_signals_in, "out", "signals", &json_signals_out);

pjungkamp · 2026-07-29T07:40:20Z

+    }
+    logger->debug("Input value {}", val);
+    switch (signalIn[i].type) {
+    case fmi3_base_type_enu_t::fmi3_base_type_float64:


Suggested change

case fmi3_base_type_enu_t::fmi3_base_type_float64:

using enum fmi3_base_type_enu_t;

case fmi3_base_type_float64:

This is just a suggestion. You can introduce a using enum statement before the first case statement to make the cases a little more readable.

pjungkamp · 2026-07-29T07:55:06Z

+  }
+
+  parse_signal(json_signals_in, true);
+  parse_signal(json_signals_out, false);


It seems that you only need the name from the in.signal/out.signals. That name is already parsed as part of Node::parse above. You can get the names by iterating the signal lists from getInputSignals or getOutputSignals, which would be the more idiomatic approach here.

pjungkamp · 2026-07-29T07:56:00Z

+static NodePlugin<FmuNode, n, d,
+                  (int)NodeFactory::Flags::SUPPORTS_READ |
+                      (int)NodeFactory::Flags::SUPPORTS_WRITE |
+                      (int)NodeFactory::Flags::SUPPORTS_POLL>


Does your node support poll? Seems to me like it doesn't.

riteshk001 requested review from n-eiling and stv0g as code owners June 17, 2026 12:22

riteshk001 and others added 7 commits June 29, 2026 15:19

feat (node-fmu): New node fmu using FMI3.0

26b1d19

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

fix (node-fmu): Fix pre-commit and SPDX error

1923827

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

feat (node-fmu): Add yaml files for node fmu for documentation

4c1c684

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

fix (node-fmu): Fix SPDX author name for fmu node

ac2fcd5

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

fix (node-fmu): Fix author in SPDX header

9f4fe99

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com> Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

Trigger CI

c5d692a

Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

Trigger CI with sign-off

2f6b5e9

Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

al3xa23 force-pushed the node-fmu branch from 4dc0195 to 2f6b5e9 Compare June 29, 2026 13:19

fix (node-fmu): Fix fmu simulations with no input signals

dd5cbbb

Signed-off-by: Ritesh.K <riteshkarki6@gmail.com>

stv0g changed the title ~~Add new node type FMU.~~ Add new node-type FMU Jul 9, 2026

stv0g requested changes Jul 9, 2026

View reviewed changes

stv0g added the node::fmi label Jul 9, 2026

Update copyrights, email, format

e055d5e

Signed-off-by: Alexandra <alexandra.bach@eonerc.rwth-aachen.de>

al3xa23 requested a review from pjungkamp July 29, 2026 07:16

pjungkamp requested changes Jul 29, 2026

View reviewed changes

stv0g changed the title ~~Add new node-type FMU~~ Add new FMU node-type Jul 29, 2026

	case fmi3_base_type_enu_t::fmi3_base_type_float64:
	using enum fmi3_base_type_enu_t;
	case fmi3_base_type_float64:

Uh oh!

Conversation

riteshk001 commented Jun 17, 2026

Uh oh!

stv0g left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pjungkamp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants