The current suite of tests for the class Material(), included in the file _testmaterial.py, covers only some of the possible class capabilities.
In test_material_from_coeff() and test_material_coeff_from_file(), tests are conducted only for one set of coefficients for each property, and at one value of temperature. They can be merged and expanded in order to test different order polynomials at temperatures that cover the whole validity range for each property.
test_material_from_table() defines an object Material for all possible coolants, each of them at a single temperature. Then it verifies that each material object has all properties as attributes, and that they are all positive. Also in this case, the range of temperatures should be expanded. Moreover, values in between the temperatures of the table should be included, in order to further test the interpolation capability of the code.
test_sodium_interpolated_value() is used to test that dassh properly interpolates sodium properties, but it only focuses on the interpolation between two values of the density. Similar tests are missing for other materials. Interpolation capability should be tested more extensively for all materials and all properties, over the whole validity range. The same consideration can be extended to properties computed with lbh15.
tests for lead, bismuth and LBE (test_lead(), test_bismuth(), and test_lbe()) are not passed at the moment. This is due to the fact that expected values are computed separately by lbh15, while tested values come from interpolation, which is the default option in dassh. In these tests, the lbh15 function should be switched on, in order to verify the correct functioning of the library call in the code. Then, similar tests should be added for interpolated values.
In addition to these considerations, the structure of the material test file can be re-organized and improved by defining a single test class, and by automatizing the generation and management of expected properties data (ex. in test_lead() etc.), and of coefficients to be used in test_material_from_coeff(), avoiding hard-coded values.
Property interpolation is performed by means of the numpy.interp() function, which is intended for strictly increasing monotonic values of temperature, but does not raise an error in case this does not happen. A check on the strict monotonicity of the temperature values in tables should be added in the source code, in the material.py file. Then, two new tests should be added, to check that an error is raised in case of two equal temperatures and of non-increasing values.
If values of properties are negative, missing, or zero, they are skipped and interpolation is done using the adjacent values: a warning is additionally written only in case of negative values. The missing and zero value cases are tested in test_table_with_missing_values(). We would prefer to avoid making assumptions on negative or zero values of the properties, thus changing this behavior by raising an error.
Changes related to the source code such as checking on the strict monotonicity of temperatures in tables and the management of negative, zero or missing values will be addressed in issue #4.
The current suite of tests for the class
Material()
, included in the file _testmaterial.py, covers only some of the possible class capabilities.test_material_from_coeff()
andtest_material_coeff_from_file()
, tests are conducted only for one set of coefficients for each property, and at one value of temperature. They can be merged and expanded in order to test different order polynomials at temperatures that cover the whole validity range for each property.test_material_from_table()
defines an objectMaterial
for all possible coolants, each of them at a single temperature. Then it verifies that each material object has all properties as attributes, and that they are all positive. Also in this case, the range of temperatures should be expanded. Moreover, values in between the temperatures of the table should be included, in order to further test the interpolation capability of the code.test_sodium_interpolated_value()
is used to test that dassh properly interpolates sodium properties, but it only focuses on the interpolation between two values of the density. Similar tests are missing for other materials. Interpolation capability should be tested more extensively for all materials and all properties, over the whole validity range. The same consideration can be extended to properties computed with lbh15.test_lead()
,test_bismuth()
, andtest_lbe()
) are not passed at the moment. This is due to the fact that expected values are computed separately by lbh15, while tested values come from interpolation, which is the default option in dassh. In these tests, the lbh15 function should be switched on, in order to verify the correct functioning of the library call in the code. Then, similar tests should be added for interpolated values.In addition to these considerations, the structure of the material test file can be re-organized and improved by defining a single test class, and by automatizing the generation and management of expected properties data (ex. in
test_lead()
etc.), and of coefficients to be used intest_material_from_coeff()
, avoiding hard-coded values.Property interpolation is performed by means of the
numpy.interp()
function, which is intended for strictly increasing monotonic values of temperature, but does not raise an error in case this does not happen. A check on the strict monotonicity of the temperature values in tables should be added in the source code, in the material.py file. Then, two new tests should be added, to check that an error is raised in case of two equal temperatures and of non-increasing values.If values of properties are negative, missing, or zero, they are skipped and interpolation is done using the adjacent values: a warning is additionally written only in case of negative values. The missing and zero value cases are tested in
test_table_with_missing_values()
. We would prefer to avoid making assumptions on negative or zero values of the properties, thus changing this behavior by raising an error.