Remove meshmodifiers and reconfigure problems/examples directory

[cticenhour]

See idaholab/moose#15980

Tagging @csdechant for review

[csdechant]

Just a note, some of the input files in the Problem directory still uses MeshModifiers. If there is no rush for this PR, I can edit those files later tonight, or we can change those input files next PR.

[cticenhour]

I can take a look at those. There isn't a crazy rush here, as there are many other projects that need to be fixed up before the MOOSE PR can move forward. Also looks as though there is a Mac issue I need to look at as well...I am surprised because the object I removed wasn't used by any of the tests any longer.

I've been a proponent of removing the problems directory altogether, but I can see its value as an easy starting point if we are smart about it. I propose making symlinks in that directory (and perhaps renaming it to examples) to their corresponding tests. Then we can avoid having to worry about changes as that occurs naturally via test modifications. I've done this in my SPS work, and it works well.

Tagging @lindsayad and @keniley1 for their thoughts. I don't mind rolling any changes into this PR.

[moosebuild]

Job Mac Test on 92c184c : invalidated by @cticenhour

Compiler doesn't support openmp?

[lindsayad]

I'd rather keep the inputs in problems, rename them to examples, or move them to tests (if we add corresponding Tests specs) instead of creating symlinks.

…

On Tue, Oct 20, 2020 at 10:09 AM MOOSE Build ***@***.***> wrote: Job Mac Test <https://civet.inl.gov/job/598601/> on 92c184c <92c184c> : invalidated by @cticenhour <https://github.com/cticenhour> Compiler doesn't support openmp? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOGA4GCMV3BTQUG46FJYBTSLW76BANCNFSM4SYRSHQA> .

[cticenhour]

Many, if not all, of them already have test specs AFAIK - we just have to remember to hop up and make the same change we make to their tests. That's why I suggested the symlink. Any particular reason why you don't want that? It really helped us organize in Freya.

[lindsayad]

I suppose that a symlink is fine. Just seems silly to have any redundancy. Best would be to totally remove problems, but if there are things in problems that are too big to be Exodiff tests (or similar level of detail tests) then I think it probably makes sense to keep the Problems directory and have those inputs checked with `check_input`. Then it may indeed be best to rename it to examples.

…

On Tue, Oct 20, 2020 at 10:20 AM Casey Icenhour ***@***.***> wrote: Many, if not all, of them already have test specs AFAIK - we just have to remember to hop up and make the same change we make to their tests. That's why I suggested the symlink. Any particular reason why you don't want that? It really helped us organize in Freya. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOGA4FV4LKCZ3OONRKULZTSLXBG3ANCNFSM4SYRSHQA> .

[cticenhour]

Thanks for your thoughts. I'm very happy to remove it altogether as I've mentioned in the past - just wanted to throw an alternative out there to get some feedback. We wanted to make it obvious in Freya what were the best examples for functionality, since the tests we have can get quite granular. Zapdos is a bit different, since many of our tests are fully-formed problems. I'm going to go through the current problems directory and see what might need to be moved over to tests and what is duplicated.

[lindsayad]

Yea it's a little tough...I think "examples" is the most clear conveyer of the meaning that users should look there to learn. I think "problems" is a bad name altogether (of course all the critique I'm offering up is of my own creation :-) But I was a very young apprentice in the beginning :-))...it's like are these problems that Zapdos can't solve? I'm also very used to just telling new moose users "go look in tests" for examples. But the word "tests" doesn't convey that meaning straightaway. Maybe I do like the idea best of having an "examples" directory and if we want some of our tests to be "examples" then we do those symlinks. Bravo!

…

On Tue, Oct 20, 2020 at 11:15 AM Casey Icenhour ***@***.***> wrote: Thanks for your thoughts. I'm very happy to remove it altogether as I've mentioned in the past - just wanted to throw an alternative out there to get some feedback. We wanted to make it obvious in Freya what were the most obvious examples for functionality, since the tests we have can get quite granular. Zapdos is a bit different, since many of our tests are fully-formed problems. I'm going to go through the current problems directory and see what might need to be moved over to tests and what is duplicated. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOGA4AQ7AMLVSB2GHIP6TLSLXHS7ANCNFSM4SYRSHQA> .

stale

[cticenhour]

OK.... so there's a ton here. problems still exists, but remaining within is only @csdechant's acceleration work examples, non-accelerated examples, and a @keniley1's CRANE example for the AD action. Tests should be made for these, perhaps, for inclusion in an eventual examples directory, but I am pushing that to the next PR, since the MeshModifiers stuff needs to be removed sooner rather than later.

A summary of the rest of the changes:

• All Schottky and reflections input files have been given Syntax Checks, as exodiff tests were never made for them.
• All troubleshooting and test Python scripts in problems have been removed. ToCSV.py has been preserved and moved to scripts.
• MeshModifiers documentation pages within Zapdos have been removed.
• New tests have been created:
  • thesis_example -- a "coffee creamer" MOOSE example from @lindsayad's thesis. Let me know if you want me to get rid of it, but since it was mentioned, I figured it should remain somewhere user-accessible.
  • water_only [syntax check] -- this was a simple input file that showed usage of the Water Material. As this object is tested elsewhere, I didn't think another exodiff was necessary, but a simple usage example should be preserved.
• Out-of-date duplicates of mean_en, TM, and current_carrying_wire were removed.
• Added missing geo files to their relevant tests for reference.
• Removed orphaned mesh files in problems.
• Removed old troubleshooting inputs.
• Removed SigmaMat and untested input file in favor of ADSurfaceCharge.

Whew....I think that's it. Please let me know if you all would like me to squash this down a bit.

[csdechant]

Everything looks good to me. Unless anyone has any comments, I think this PR is ready to go.

[cticenhour]

Sounds good - I'll give folks a chance to comment and merge late tonight or in the morning.