comp-chem/cp2k
1
0
Fork 0
mirror of https://github.com/cp2k/cp2k.git synced 2026-07-28 14:15:19 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

tests: Remove redundant and trivial READMEs

Browse source
This commit is contained in:
shoshijak 2019-10-21 14:35:38 +02:00 • committed by Ole Schütt
parent 5e9b32bdf2
commit 34fb58d896
9 changed files with 0 additions and 107 deletions
Download patch file Download diff file Expand all files Collapse all files

13
tests/QS/regtest-gapw/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-gpw-1/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-gpw-3/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-gpw-4/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-ot-1-vib/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-ot-1/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-ot-2/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

13
tests/QS/regtest-ot/README
View file

@ -1,13 +0,0 @@
This directory should contain a number of testcases that can be used
to check that a given feature remains in a working state, and that
e.g. bugs do not reappear. The idea is that all inputs in this directory
will be executed from time to time automatically and that results will be
compared to older data.
As we should have *many* tests here, I would like them to be fast (e.g. less than 1min.
on a normal pc with an sdbg version of the code). Since these tests do not need to return
meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs,
small EPS_DEFAULT, ...
Adding a test is very simple. Commit the .inp and add an entry to TEST_FILES. These files
will be run in order, so that a job that wants a restart is no problem.

3
tests/QS/untested_inputs/README
View file

@ -1,3 +0,0 @@
This directory contains input files, which have a more meaningfull setup compared to the regtests, but that are not
checked at every single commit about syntax, possible keyword changes. Checks are done at a very unregular interval of
time. It may be possible that cp2k may have problem in digesting them.