Documentation for acoustic_1d_imex, testequation0d and vanderpol

[lisawim]

#286

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (433f026) 73.29% compared to head (116a318) 73.29%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #340   +/-   ##
=======================================
  Coverage   73.29%   73.29%           
=======================================
  Files         264      264           
  Lines       22015    22015           
=======================================
  Hits        16135    16135           
  Misses       5880     5880           

Files Changed	Coverage Δ
...ns/problem_classes/AcousticAdvection_1D_FD_imex.py	98.00% <ø> (ø)
...implementations/problem_classes/AllenCahn_2D_FD.py	95.28% <ø> (ø)
...ementations/problem_classes/AllenCahn_2D_FD_gpu.py	0.00% <ø> (ø)
...mplementations/problem_classes/AllenCahn_2D_FFT.py	0.00% <ø> (ø)
...mentations/problem_classes/AllenCahn_2D_FFT_gpu.py	0.00% <ø> (ø)
...mplementations/problem_classes/AllenCahn_MPIFFT.py	80.15% <ø> (ø)
...entations/problem_classes/AllenCahn_Temp_MPIFFT.py	81.30% <ø> (ø)
...C/implementations/problem_classes/BuckConverter.py	100.00% <ø> (ø)
...ementations/problem_classes/FastWaveSlowWave_0D.py	100.00% <ø> (ø)
pySDC/implementations/problem_classes/Lorenz.py	100.00% <ø> (ø)
... and 3 more

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lisawim]

I have also added documentation for the Allen Cahn 2D problems. The 1D problems will follow some time in another PR.

[pancetta]

Great, thanks! I really appreciate all the effort you're putting into this.

I noticed that the AC descriptions are not correct. This is partially due to the confusion in the literature (incl. my own publications). Some of the problems are for u in [0,1], others are for u in [-1,1]. If you really want to deal with this, please cross-check the AC descriptions with the actual implementations and do not/never rely on what's written in the papers. It's ok to just drop it for now, if you don't want to go down that rabbit hole.

[lisawim]

Oh yes, sure! I will check and change that!

[lisawim]

Please do not merge it yet, I did not correct the descriptions from the Allen-Cahn problems yet. Will do that later!

[brownbaerchen]

Good job! I have been wondering about line breaks in comments for a while and maybe this is the place to settle this. (Maybe not, sorry...)
Anyways, in the days of flake8, the maximum line length was enforced for all lines, but black and flakeheaven allow for comments going beyond the maximum line length. So what should we do now? Do we enforce the maximum line length in comments manually, which I believe you did here and which I have been doing more or less, or do we insert line breaks wherever we want and let the editor do its thing? The latter is maybe more pretty when the line length of the editor is shorter than the maximum allowed one, which results in all sorts of weird line breaks. This is, for instance, the case for me here on GitHub.

[lisawim]

No, I think that's the right place to talk about that! In my view it's only a "beauty" thing of doing line breaks or not. But I can speak for myself: I'm hating to scroll to the right to read documentation (probably it depends). I wanted do use line breaks, but "sometimes" it could happen that I use the maximum line length anyways..

[pancetta]

Anyway, ready to merge?

[lisawim]

So anyway means that it is okay that the descriptions of the Allen-Cahn problems using AC descriptions does not contain the correct version of using either $u \in [-1, 1]$ and $u \in [0, 1]$ yet, which I didn't correct yet? In that case it's ready to merge.

[pancetta]

Do you think you could correct the AC things today? Alternatively, you could put the AC stuff into a second PR.

[lisawim]

Puh, I don't think so.. I need some time to go through literature to fix that. Probably it's better to put it in a separate PR. How can I do that?

[pancetta]

Understandable.. for extracting the AC stuff into a separate PR, I think we need a git/Github magician. Volunteers?

[lisawim]

I can close this PR, creating another branch and only do the changes without the AC classes?

[pancetta]

That may actually be the easiest solution!

[brownbaerchen]

I think the easiest thing would be to first create a new branch with only the AC changes:

git checkout master
git checkout -b AC_only
git checkout prob_class_docu2 -- <AC_files>
git commit -a 

Then, remove the AC changes from the current branch

git checkout prob_class_docu2
git checkout master -- <AC_files>
git commit -a
git push

Of course, I am too late :D Also, I am certainly no git Houdini. I do back-alley git magic at best.

[lisawim]

I guess this won't be the last time having this problem. Next time I'll try that out!