Add tutorials

[spyridon97]

This PR fixes several documentation warnings, and adds tutorials for the basic ADIOS concepts

This PR fixes #3793.

[anagainaru]

Two questions/comments

1. You moved a bunch of examples from bpWriteRead{name} to bpTimeWriteRead{name}. What is the significance of Time in the name? I would keep the name the way it was just because it was shorter and still intuitive (unless there is a reason for the Time addition).
2. You added a bunch of skeleton codes (which is great for the tutorial text you have). I would place them all in a separate folder instead of the hello

I left a bunch of comments with a few typos, but other than this it looks really good. Good job !

[spyridon97]

1. You moved a bunch of examples from bpWriteRead{name} to bpTimeWriteRead{name}. What is the significance of Time in the name? I would keep the name the way it was just because it was shorter and still intuitive (unless there is a reason for the Time addition).

I did it because bpWriteRead is kinda very vague, and there are a bunch of examples like that. This particular examples show how to write and read time steps. And that's how i also use them.

2. You added a bunch of skeleton codes (which is great for the tutorial text you have). I would place them all in a separate folder instead of the hello

@vicentebolea and I decided that the best place to put them is next to the actual code so that we don't forget to update them, if needed.

[eisenhauer]

I did it because bpWriteRead is kinda very vague, and there are a bunch of examples like that. This particular examples show how to write and read time steps. And that's how i also use them.

I'd use "Step" rather than "Time" in the name. (In general I think we've been trying to move away from the "timestep" nomenclature, dropping time and keeping step.

[spyridon97]

I did it because bpWriteRead is kinda very vague, and there are a bunch of examples like that. This particular examples show how to write and read time steps. And that's how i also use them.

I'd use "Step" rather than "Time" in the name. (In general I think we've been trying to move away from the "timestep" nomenclature, dropping time and keeping step.

So you would prefer to rename the examples to bpStepWriteRead*?

And is it okay if i stick to timesteps for the name of the particular tutorial?

[eisenhauer]

So you would prefer to rename the examples to bpStepWriteRead*?
Definitely would be my preference. "Time" doesn't appear in our APIs, but "Step" is prominent. ("Timestep" is in some SST engine parameters, but we likely should change that at some point.)

And is it okay if i stick to timesteps for the name of the particular tutorial?
I'd ask @pnorbert to weigh in on that. I know about the de-emphasis on Timestep in favor of Step, but not as much about the why's. Norbert has done the demo and tutorials enough to opine on this.

[spyridon97]

So you would prefer to rename the examples to bpStepWriteRead*?
Definitely would be my preference. "Time" doesn't appear in our APIs, but "Step" is prominent. ("Timestep" is in some SST engine parameters, but we likely should change that at some point.)

And is it okay if i stick to timesteps for the name of the particular tutorial?
I'd ask @pnorbert to weigh in on that. I know about the de-emphasis on Timestep in favor of Step, but not as much about the why's. Norbert has done the demo and tutorials enough to opine on this.

I decided to remove the word time from everywhere in this set of tutorials, I hope this change addresses all of your concerns.

[vicentebolea]

The crusher failure can be resolve if you "update the branch", IMPORTANT use rebase update

[vicentebolea]

[spyridon97]

@vicentebolea the bpls results were added, can you check them and approve this PR?

[vicentebolea]

The changes with regards the bpls usage looks good. 👍

As for the the several changes in the documentation unrelated to the tutorials, they look good in a first glance, however, while it is great to improve things here and there, it is best to do it in a different PR. The reason for this is that opening many fronts will both slow the review process and confuse reviewers.

[spyridon97]

The changes with regards the bpls usage looks good. 👍

As for the the several changes in the documentation unrelated to the tutorials, they look good in a first glance, however, while it is great to improve things here and there, it is best to do it in a different PR. The reason for this is that opening many fronts will both slow the review process and confuse reviewers.

I will keep that in mind for future PRs.

[vicentebolea]

Looks good, couple of comments, let the CI pass before making change so we can see the crusher CI result

[vicentebolea]

Upon CI passing

[spyridon97]

Upon CI passing

There seems to be unrelated tests failing. Shall i merge?

[vicentebolea]

Indeed, it is unrelated, ready to merge!