moose failed tests

221 views
Skip to first unread message

dealm...@gmail.com

unread,
May 19, 2018, 1:32:28 PM5/19/18
to moose-users
Hello,
I ran this on a laptop with 2 cores:

misc/exception.parallel_exception_residual_transient ......................................... FAILED (ERRMSG)
outputs/console.console_off ................................................. FAILED (EXPECTED OUTPUT MISSING)
preconditioners/pbp.lots_of_variables ....................................................... FAILED (TIMEOUT)
--------------------------------------------------------------------------------------------------------------
Ran 1591 tests in 2168.0 seconds.
1588 passed, 80 skipped, 0 pending, 3 FAILED

Is there a place to check what these messages mean for my installation?

Thanks,
--
Valmor

Miller, Jason M

unread,
May 21, 2018, 9:19:25 AM5/21/18
to moose...@googlegroups.com
Valmor,

We try and make the failed messages as self-explanatory as possible. But that can prove difficult with only x amount of available character space. The 'ERRMSG' result means the test encountered an error message of some kind within the output. While the 'expected output missing' result usually means that something that was supposed to happen, didn't. Timeout, means the test did not complete during the allotted time, and was killed by run_tests to prevent a possible never-ending-test situation (the default for all tests is 300 seconds before being considered a timeout).

The actual error for all your failed tests is 'further up' from what you have copied/pasted. What you are seeing is a sorted finalized result for all tests that can fit on one line.

You can run these tests individually using --re <test name>. If they still fail, the actual error should be easier to spot. You can also use -v to make the test 'verbose'. That is, display the output of the test even if it does not fail. For example:
  ./run_tests --re=misc/exception.parallel_exception_residual_transient -v

Will run the one test that appears to have caused an error message on your machine.

To figure out why each of these tests failed, we would like to see the verbose output. So if you would, run each of these tests again, using --re -v and copy/paste those results :)

Thanks!
Jason






--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/e813f778-baa7-424d-a81b-5f55d55d89e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Derek Gaston

unread,
May 22, 2018, 1:40:32 PM5/22/18
to moose...@googlegroups.com
That said: these three are not terribly important... so you would be just fine to ignore these failures.

It is a quizical set of tests to fail though - so I wouldn't mind seeing the error messages that are coming out.

BTW: The pbp_lots_of_variables timeout isn't a big deal... it just means your machine may be pretty slow or was overloaded at the time.

Derek

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Ravi S.

unread,
May 22, 2018, 3:32:19 PM5/22/18
to moose-users
Hi

I just installed moose and my system failed nine tests.

Can someone please let me know if they are critical and why I might have failed and how to fix them?

Thank You

Rav
ErrorsMooseInstallation

Miller, Jason M

unread,
May 22, 2018, 4:05:53 PM5/22/18
to moose...@googlegroups.com
I would say they are non-critical at the moment. You might want to run each failed test one at a time with a lower -j (or no j) to make sure that they do pass. If they still fail we can go from there (perhaps adjust the timeout length if you are that serious). To run individual tests you can use the --re argument. Example:

  ./run_tests --re materials/material.exception_material_parallel_rank1

How many cpus (-j) did you supply run_tests to begin with? Also, how many cores does you machine have available? If you are using one of our moose-environment packages, you can check an environment variable which explains how many cores your machine has available:  echo $MOOSE_JOBS

Thanks!
Jason



To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Ravi S.

unread,
May 22, 2018, 4:24:43 PM5/22/18
to moose-users
Hi Jason,

Thank you for your reply. I am running moose on an Ubuntu platform on VirtualBox on my desktop.
Running echo $MOOSE_JOBS returned 1. That explains several of the tests failed, I suppose? Since the message returned (in the file I attached to the previous request) said that there is a minimum # of cpus (2 or 4 etc)?

As per your suggestion, I ran each failed test. The ones that didn't have a min_cpus requirement passed. Those that did were skipped. So I am guessing I am all set...?

Sincerely
Ravi

Miller, Jason M

unread,
May 22, 2018, 4:54:52 PM5/22/18
to moose...@googlegroups.com
Only having 1 core available and only (or mostly) the min_cpus= tests are timing out... that certainly makes sense being a single core issue.

Also, once you do set a -j, you are setting a hard limit to how many CPUs the TestHarness will allow a test to consume. If a test requires more than this number, it will be skipped, with a caveat: "insufficient slots" attached to the result. 

Running the tests without setting a -j allows the TestHarness to over subscribe the amount of CPUs a single test will use (but will only launch 1 test at a time). The TestHarness will alert you for tests that do this, with the caveat 'OVERSIZED' attached to their results.

I must apologize for asking you to run that one individual test with --re =D. I did not check what that test would actually do... 'materials/material.exception_material_parallel_rank1' test requires other tests to be run first. And thus, I created an impossible situation for the TestHarness (skipped dependency).

Anyways, here is an example of what hard limits, soft limits, and 'just enough' will do:

Hard Limit (setting a -j):

[~/projects/moose/test]> ./run_tests --re materials/material.exception_material -j 1
materials/material.exception_material_serial .......................................... OK
materials/material.exception_material_parallel_rank1  [insufficient slots,min_cpus=4] SKIP
materials/material.exception_material_parallel_rank0 ........... [skipped dependency] SKIP
------------------------------------------------------------------------------------------
Ran 1 tests in 2.6 seconds.
1 passed, 2 skipped, 0 pending, 0 failed

Soft Limit (no -j):

[~/projects/moose/test]> ./run_tests --re materials/material.exception_material
materials/material.exception_material_serial .......................................... OK
materials/material.exception_material_parallel_rank1 ........... [min_cpus=4,OVERSIZED] OK
materials/material.exception_material_parallel_rank0 ........... [min_cpus=4,OVERSIZED] OK
------------------------------------------------------------------------------------------
Ran 3 tests in 2.7 seconds.
3 passed, 0 skipped, 0 pending, 0 failed

Just Enough (-j >= min_cpu requirements)

[~/projects/moose/test]> ./run_tests --re materials/material.exception_material -j 4
materials/material.exception_material_serial .......................................... OK
materials/material.exception_material_parallel_rank1 ..................... [min_cpus=4] OK
materials/material.exception_material_parallel_rank0 ..................... [min_cpus=4] OK
------------------------------------------------------------------------------------------
Ran 3 tests in 2.7 seconds.
3 passed, 0 skipped, 0 pending, 0 failed


You might want to look into increasing the amount of CPUs available to your VM. Your machine most likely has multiple cores available, and will greatly increase the speed at which you can run tests/problems.
...and another apology, if I have over-explained the CPU scheduling routines...

Cheers,
Jason




To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Ravi S.

unread,
May 23, 2018, 11:20:14 AM5/23/18
to moose-users
Jason, your explanations are most welcome as they help me understand! Thank you.
When I ran the original make, I used -j8. I didn't know what the argument was. I was just following directions on installing moose. Now I understand better.
I see my CPU has 4 cores. Thank you for pointing out that I could assign more cores to my VM. I did a quick internet search and fiured out how to do it. That should help with the speed.

BTW is there a manual for moose? Something I could read to learn up on creating a simulation? Maybe I am not looking hard enough, but I haven't come across one.

Ravi

Miller, Jason M

unread,
May 23, 2018, 12:49:21 PM5/23/18
to moose...@googlegroups.com
Ravi,

Glad you got it sorted! Did you experience any speed up while running all the tests?

We have discontinued creating manuals (ability to do so via LaTeX. Ok, the stuff is still there to do it, but we don't maintain it). The reason for this, is that the material contained within quickly becomes dated and was difficult to maintain (both LaTeX and an HTML-online format in an eye-pleasing way). Instead, we maintain only an online wiki. The current wiki can be found on the main page on mooseframework.org. Another location of useful information would be the documentation link located on the main page as well.

The good news is, we are currently in the processes of revamping our documentation system. One that is created based on the content within the moose repo itself (so it is always current and tied together). You are welcome to peruse the new documentation system located at https://mooseframework.org/moose. This new system is under development and far from complete... but this will eventually become 'the manual' per-say.

Cheers!
Jason


To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Ravi S.

unread,
May 23, 2018, 6:02:09 PM5/23/18
to moose-users
Jason,
Definitely. The same tests that took around 10 seconds yesterday took roughly half as long just now.
Thank you for the link to mooseframework. I am checking it out right now.
I don't see you in the Argonne system, so I assume you are not here. Curious if you are at the Idaho lab.

Miller, Jason M

unread,
May 24, 2018, 8:33:52 AM5/24/18
to moose...@googlegroups.com
Good to hear!

Yep, I am located with the rest of the MOOSE team here at the INL...



To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Ravi S.

unread,
May 24, 2018, 3:45:10 PM5/24/18
to moose-users
Jason,
I have some basic questions. Should I be looking to download Cubit if I want to make ageometry and mesh it for use in a MOOSE simulation? I have a relatively simple geomtery. Basically a quartz tube with a copper hoop and some brazing paste. The idea is to examine the hoop stresses as the set up is heated up past the melting point of the brazing material and then cooled down, with the brazing material filling the space between the two concentric walls.

Could I try that with the elementary meshing available in MOOSE?

Derek Gaston

unread,
May 24, 2018, 5:19:15 PM5/24/18
to moose...@googlegroups.com
Ravi,

You're going to need a real "mesher" for that.  Cubit/Trelis or GMesh at least.

Derek

Reply all
Reply to author
Forward
0 new messages