Migrate ParModelica to the NF

[casella]

We should migrate ParModelica to the new front-end, since the old front end has no longer been maintained for some time, and has a number of limitations and shortcomings compared to the new one.

[mahge]

Ya I have been thinking about this. The NF is quite well structured so it should not be very difficult to do. We mostly need to pass through the ParModelica info to SimCode where most of the processing is done.

The things (the ones that I think of now) that need to be done are:

• Some scope checks to make sure variables are used in "parallel" scope
• Filtering out used variables from the body of parallel for loops.
• Some new constructs/statements (e.g. PARFOR)
• One new attribute to variables to signify parallelism

All and all I do not think it will be a lot of work.

[perost]

* One new attribute to variables to signify parallelism

This is already done, the NF doesn't use it for anything but it's part of the variable attributes and passed through to the DAE. I don't know if it's correct since we don't use it, but I see no reason why it shouldn't be. The NF does not handle parfor loops or anything else ParModelica-related though.

[casella]

@mahge maybe there was a misunderstanding on my side. It would be of course nice to have ParModelica supported by the NF, otherwise it gets lost. But the most important thing now is to have ParModAuto supported by the NF. Is that already the case?

[mahge]

Yes. They are different approaches and implementations. ParModAuto is of course supported by the NF since it does need anything special from the NF. It will also be supported by the new BackEnd as long as it results in the same SimCode structure. It is when we change the SimCode, Codegen and Runtime System that we will worry about it :)

[mahge]

Just for context ParModelica (a.k.a. ParModExp) is an explicit parallel programming, language extension for Modelica. Things like parallel for loops, manual thread control, synchronization..., It's main purpose is to have a way of telling a Modelica compiler how to parallelize some heavy data parallel computation such as a matrix multiplication. It extends the language with new constructs so it will be affected by major switches to the components of the compiler from the parser all the way to the runtime system.

As it is now ParModelica is very low priority as I see it. To my knowledge it is only used by very few people. So we can delay it as much as we can and keep the NF as pristine as possible for as long as we can.

[casella]

Yes. They are different approaches and implementations. ParModAuto is of course supported by the NF since it does need anything special from the NF.

Yes, that's what I though, in fact.

It will also be supported by the new BackEnd as long as it results in the same SimCode structure.

Unless we are using the array-preserving variant of it, I guess.

It is when we change the SimCode, Codegen and Runtime System that we will worry about it :)

OK.

[mahge]

Unless we are using the array-preserving variant of it, I guess.

Hmm. Maybe. I am not sure about this. There are some doors that the array-preserving opens. Some make me hope good things some otherwise. We will worry about it when the time comes 😅

[perost]

I had a look at what the old frontend actually does with parfor-loops, and it seems it just collects the variables in them and checks that they are parglobal. Since that's easy to do I implemented it in #8260, along with some other minor fixes.

The current test cases call the functions directly in a script though, and it seems we always use the old frontend in that case. So I don't really know how to test it beyond just checking that the flat output is correct.

[mahge]

The current test cases call the functions directly in a script though, and it seems we always use the old frontend in that case.

Does this mean setting the NF with flags in the script does not work for calling evaluating any function using a script? Not just for ParModelica? That is a bigger problem we have to figure out I guess.

So I don't really know how to test it beyond just checking that the flat output is correct.

That is alright. I can check them manually without the scripts.

Thank you again. Very much appreciated.

[perost]

The current test cases call the functions directly in a script though, and it seems we always use the old frontend in that case.

Does this mean setting the NF with flags in the script does not work for calling evaluating any function using a script? Not just for ParModelica? That is a bigger problem we have to figure out I guess.

Yeah, calling a function directly in a script seems to always use the old frontend. The NF doesn't support compiling a function and running it, it only does function interpretation or calls library functions via FFI. For the scripting stuff we should be able to flatten functions using the NF and then generating code the usual way, but it needs some work.