Closed stvdwtt closed 2 years ago
Error from cuda
/var/jenkins/workspace/adamantine/application/adamantine.cu(77): error: namespace "adamantine" has no member "validate_input_database"
One of the test times out. I think the problem is due to the new machines that we are using for the CI. We don't control what kind of CPU we get so it's possible we got something slower. Can you change line 74 in ci/jenkins_config
to
sh 'ctest --timeout 1800 --no-compress-output -R test_ -T Test'
This doesn't help. I think the only way is to step in with a debugger to see what's going on. Do you know how to do it?
Is it possible that it is still legitimately timing out? The test test_material_deposition_2
is a two-MPI-task version of the test, right? It looks like that took over 1000s.
18/23 Test #19: test_material_deposition_1 .......***Timeout 1800.11 sec
Start 20: test_material_deposition_2
19/23 Test #20: test_material_deposition_2 ....... Passed 1071.34 sec
I guess so. I wonder why the time of that test has increased so much. The other tests run in about the same amount of time as they did a week ago. You can try increasing the time again and see it that fixes it.
We will need to investigate why this test is suddenly so slow. Since this capability is badly needed, I will merge it now and we can fix the test later on.
This adds a check to validate the input file at the start of the simulation. Most of the input checks in the code have been moved here, with a few exceptions. In cases where there is a defined list of options, the core part of the code still has some
else
statements with thrown exception if input doesn't match the options. I think this helps the readability of the code and doesn't add much complexity. The other case is when the validation is intricately tied to the parsing (e.g. checking for the experimental camera files). At least at this point, I didn't want to have to repeat too much of the logic/parsing process in two places.To test the input validation, I tried to balance coverage, length, and my time. It isn't exhaustive (e.g. I don't consider all possible combinations of valid inputs), but it is pretty comprehensive. If there are important checks that I'm missing, I'm happy to add them here or in another PR.
I also updated the README to list more directly which input are required and which are not.
I did not change the default behavior for any of the inputs in the PR, although at some point we may want to reconsider which inputs have default values and which do not.