Frontend for FortranTestGenerator

[chovyy]

Hi all,

there are some features left that I have added to serialbox-ftg and not yet integrated to serialbox2. serialbox-ftg is based on serialbox1 and used by the FortranTestGenerator.

The features are:

1. Routines for allocating allocatables and pointer variables based on there bounds stored in the halo fields.
2. Bullshit recognition, i.e. do not try to write fields that seem to be uninitialized pointers or the like. Since you cannot tell it for sure (ASSOCIATED only works if the pointer was at least initialized with NULL()), I have implemented a heuristic for that.
3. Do not try to read fields that do not exist (without terminating with error).
4. Always store the address of a written field as meta info.
5. The option to register fields of any type without actually writing the data, just to store the meta data.

That goes all beyond serialbox' core functionality, so I'm not sure what will be the right way to integrate it. I think, there are three options:

• Just add them to m_serialize.f90 as done in serialbox-ftg.
• Create a FortranTestGenerator frontend and put it to src/serialbox-fortran/ or somewhere else.
• Create a FortranTestGenerator frontend and keep it outside of serialbox2.

Each feature could also be handled differently.

What do you think?

Cheers, Christian

[havogt]

@clementval Can we discuss this next Monday/Tuesday?

[clementval]

@havogt On Monday would be fine

[havogt]

@chovyy What are your long-term plans for serialbox? The point is, we don't want to move stuff into the project which increases maintenance on our side. Therefore we would like to keep serialbox2 focused on its core functionality. On the other hand if you commit to maintaining this part, this could be a way to go. So our conclusion is to go either with your second or third suggestion depending on how much you can be/want to be involved in maintaining Serialbox2.

In summary:

• If you go with the third suggestion you could target specific Serialbox2 releases with your code and you can ensure that it works with these releases.
• If you go with the second suggestion you need to provide proper testing that we realize if we break your code. Then, you would have to give help or adapt yourself the FortranTestGenerator frontend in reasonable time, otherwise it doesn't make sense to keep it inside Serialbox.

What do you think?

[chovyy]

Thanks for your answer.

Just to give you some background: I have created this serialbox-ftg fork because of things that were missing in serialbox1 or just buggy. Your colleague Will, who sometimes uses the FortranTestGenerator, argued that instead of using this "hacked" fork it would be better to have the additional functionality in the official maintained version of serialbox(2). I think, he is absolutely right and that's the reason why I have started initially to contribute to serialbox2. [@havogt, you might remember the email discussion on that.]

I would definitely be willing to maintain this part in the future. I think, it would be easier for me to do that when it's part of serialbox2 than when it's a separate library.

But anyway, I will work on it within my own serialbox2-fork and when it's finished, we can talk again about how we integrate it.

[vectorflux]

Just my $0.02: It would be great if Christian could use the official Serialbox2 release, thus obviating the need for his serialbox-ftg fork. From the discussion -- correct me if I'm wrong -- it appears that very little is still needed for that...

[lxavier]

@chovyy would be great if you could create a PR once ready. We will try to get the changes in the master so that we may use the FortranTestGenerator further.

[chovyy]

Pull request created.