Scientific software and the perils of variables
Scientific software, known as very unforgiving software, has yet again got the better of me. It all boils down to the fact that scientific software in general requires such a huge number of variables to perform even simple calculations that you have to know exactly how each variable is going to affect the final result. For example today I have been trying to use the code ‘Octopus’ (a Time Dependent Density Functional Theory code) to repeat some calculations done using the more familiar code Quantum ESPRESSO (a Time Independent Density Functional Theory code). However as parameters are different, and systems are set up in different ways, it seems to be next to impossible to repeat this calculation.
I can totally understand the reason to have so many different variables, the more variables a code has the more effectively powerful the code is, as you are able to change parameters to fit the situation. But maybe its time to try and use the same parameter name, and using the same approximations, working in the same way. In different worlds of computer programming it has become common for something that is repeated many times for different codes to become an ‘engine’, which then people can build upon adding their own interface layers, and allowing the code to evolve into different packages, but all based upon that same principle. Would it be possible to bring a ‘DFT’ engine into development, that could then be used by different codes to try to unify the menagerie of different codes into one place.
No trackbacks yet.