DARTHs cheat sheet
We recently wrote about
DARTHs are composable infrastructures whose parts are loosely connected, communicate with standard protocols and can easily be substituted. There is not such a thing like a DARTH but a DARTH solutions whose parts can be disassembled and recomposed in new solutions, exactly it happens for Linux distributions (distros). Distros need usually an integrator of resources which is a further component of DARTHs.
- Must be Open
- Provided on demand over the cloud
- Discoverable on the web
- Provided in standardized self-explanatory formats
- Retrievable on the base on open APIs on the most common computer languages
- with respect to the science
- the programming language
- The operative system
- Modelling styles and paradigm
- They are lightweight with respect to programming habits, meaning they should be minimalist in adding programming rules and aims to maintain the code short
- Variables names should be mapped into standard names that provide an unique identification
- Programs must be open source and developed with open tools
- Simulations and operations must be traceable and replicable by construction
- Chunks of data, codes and modelling solutions should organized in standard way and be deployable over the web for third parties testing snd reuse
- need to be able to easy any flavor of modelling effort through ODEs (systems of ordinary differential equations), PDEs (system of partial differential equations), MS (Statistical Modelling), ML (Machine Learning)
- should be deployed in model components (A component model is a model that is used to encapsulate equations or specific tasks into a reusable form. Components can be connected at runtime and communicate exchanging data in RAM memory)
- need to be deployable along the web on all the available platforms.
- model-to-model (components) communication should be allowed through API
- Adopt software quality testing for any component separately
- Adopting good programming practices
- Promote literate computing (and literate programming)
- They use various form of parallelism but overall, parallelism should be provided as a service without having to change programming habits of models developers.
- Workflows of tasks that can be schematize on graphs should be internally parallelized using piping methods.
- Models on grids should use middleware that separates the parallelization from the “physics” of implementation and should be as less invasive as possible.
- They can use multicores, multiprocessor, high end computers, distributed computing without necessarily direct intervention of the programmer
- They should use the natural partition of Earth surface in river catchments and subcatchments to split the computational work.
- The complex retrieval chain has to become explicit and adaptable to the modeling
- Data Assimilation must become part of the modelling chain
- The quantification of uncertainty must become inherently part of an open DARTH. Without it the quantitative indication lose their credibility.
- DARTHs must support open science, practices without which, science becomes a nonsense.
—————
TRANSCOM ISP – Free Sigma HSE Email
Level 6 Domain Names are FREE – Register Now.