Closed timofeymukha closed 1 week ago
A limitation right now is that the user simcomps do not respect the "order" keyword.
Nice! But I would suggest to create a new example for this instead of diluting tgv further ;)
Yeah, this is just for demonstration.
Nice!
I like that this would provide a nice framework to create "user modules". Since the controllers would also be initialized and all that.
I have a question: How does one compile the user_simcomp? does makeneko pick it up?
I still do not see a lot of advantages over a user just creating a module and using it in their user file. I guess in that sense I am an opponent of "everything as a simcomp" vision that a lot of you have.
But I also trust the process. So far all your suggestions have made the code better :)
Nice!
I like that this would provide a nice framework to create "user modules". Since the controllers would also be initialized and all that.
I have a question: How does one compile the user_simcomp? does makeneko pick it up?
I still do not see a lot of advantages over a user just creating a module and using it in their user file. I guess in that sense I am an opponent of "everything as a simcomp" vision that a lot of you have.
But I also trust the process. So far all your suggestions have made the code better :)
There is not really a contradiction I think, because it's exactly as you say, you create a new module and compile it with makeneko alongside your user file. So here it will be makeneko tgv.f90 test.f90
. And then I use the simcomp type inside test.f90 in the user file tgv.f90. So, if what you are adding fits into the simcomp concept, you can implement a simcomp in your module and plug it into the simulation pipleline. I think an argument for that contra putting things in user_check etc is that the simcomp encapsulates everything, so if you put your simcomp online somewhere, it is pretty clear how I add it to my case. Another discussion was that this would make it easier to integrate code developed by users, since things are already put into the correct framework from the beginning, so to speak.
Another aspect I guess is controlling when the user functionality occurs. user_check is always at the end fo the time step, which might not always be what one wants (foe example if one is changing the field in some way).
@timofeymukha and @njansson I have done a number of updates so it should now be more useful.
Instead of creating an example case as we have done so far, I decided to utilize the doxygen feature to create examples. Since what is needed here is more a code snippet of how to do it, and not an actual case.
Looks good, some minor questions, and unsure if we want to have the copyright statement with doxygen tags (strongly leaning towards a no there)
Well it's more a suggestion. It will format it directly in our documentation in a more useful way rather than it only being in the source code. Try to run make html
and look at the simcomp_executor.f90
file reference: /neko/doc/html/d8/d65/simcomp__executor_8f90.html
.
@njansson & @timofeymukha I reverted the doxygen stuff. Are we happy to merge? I guess Tim cannot officially review since its his PR and i feel i shouldn't due to the changes i made. But i can do an accept if Tim agrees.
Sorry @njansson I did a bunch of changes to the executor that need a look before merge.
Tim, I will at the stuff later today!
I ran out of time :(. But on Sunday!
@timfelle feel free to "approve" and merge!
This is a proof of concept of how user simcomps can be incorporated into the
neko_simcomps
object so that they are executed just like the ordinary ones. As a reminder, the issue is that the simcomp factory cannot know about the new simcomp types, so the init has to happen in the user file. Here I use the user initialization routine to that end, so comments are provided there. To make this work, I had to make the simcomp array inside thesimcomp_exectutor_t
to be larger than the number of simcomps in the JSON file. A better solution is to add a properadd
routine.I modify the tgv example to demonstrate things,
test.f90
is just a copy of the vorticity simcomp with a new type name. The JSON for the user simcomp is added inside a "user_simcomps" array, but of course any configuration can be used, since it is the user code that parses the JSON.I think this is in principle a pretty ok solution, which could facilitate users to encapsulate things in simcomps. I will put some more thought in how to make this as streamlined as possible.