You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we mainly use the createLWE cli to create test cases. However, this method is not necessarily well suited to cover all functionality that we have in CADET (i.e., not all unit operations support binding models etc).
Instead, we propose a new set of methods:
createPulse
createBreakthrough
which would work for all unit operations, in some cases even have analytical solutions that can be used for benchmarking and code verification, and which can each be parametrized as needed with binding models, reactions, and other features (e.g. discretization method etc.), assuming the corresponding unit operation does support that feature.
For this purpose, we should also migrate some of the helper functions implemented in #187 to a common utility module. Here we're still missing some features such as
add MCT (Multichannel Transport) model to createLWE
Other considerations
How to cover other features of CADET such as cyclic systems?
Must all this functionality be provided in C++ or is it "good enough" to implement this in Python (e.g. in CADET-Process?)
Once this is implemented, should we use a defined set of parametrized tests as a criterion to test the different implementations of CADET backends and frontends (C++ / Julia vs CADET-Process)?
The text was updated successfully, but these errors were encountered:
Currently, we mainly use the
createLWE
cli to create test cases. However, this method is not necessarily well suited to cover all functionality that we have in CADET (i.e., not all unit operations support binding models etc).Instead, we propose a new set of methods:
createPulse
createBreakthrough
which would work for all unit operations, in some cases even have analytical solutions that can be used for benchmarking and code verification, and which can each be parametrized as needed with binding models, reactions, and other features (e.g. discretization method etc.), assuming the corresponding unit operation does support that feature.
For this purpose, we should also migrate some of the helper functions implemented in #187 to a common utility module. Here we're still missing some features such as
Other considerations
The text was updated successfully, but these errors were encountered: