Welcome to Radhub’s documentation!
The Radhub website is a platform for online access to tools related to radiation effects in microelectronics. It represents a collection of codes that offer quick calculations of the natural space and terrestrial environments as well as effects models for prediction.
File parsers |
|
The Barak 2000 model |
|
The Bendel model |
|
The depthdose model |
|
The effectiveflux model |
|
The facilities model |
|
The gcr model |
|
The ionstopping model |
|
The neutron model |
|
The pfail model |
|
The PROFIT model |
|
The reliability model |
|
The RPP model |
|
The shieldose model |
|
The spe model |
|
The SRIM model |
|
The sunspot number model |
|
The worldmap model |
|
The packagename model |
Style Guideline for Scientific Code
Package names will adhere to radhub-modulename
Packages will use the radhub namespace
Module names by author is discouraged
Modules should contain or import core functions in __init__.py
Code must be stateless
Modules may not save global data other than initial data on load
Use of class objects is discouraged
Setting class object attributes other than within initialization, is prohibited
Modules should not access the file system except during load and only their own package data
Documentation should make use of the Sphinx system with numpy style annotation
Documentation for parameters and return values must include units
Deviations or corrections to published calculations must be clearly documented
Comments, in addition to documentation, are encouraged
Packages should include executable examples reproducing published figures
Published references should be included in documentation with modules or functions as appropriate
Equation references should be included in comments for functions or near lines of code as appropriate
Units should follow lines of code particularly when changes of units are involved eg # [MeV]
Variables and function names should resemble published notation. Greek letters may be replaced with similar alphabetic or written name
Codes should make use of numpy or similar vectorized and efficient libraries
Dictionaries should use descriptive key names including units
Functions should allow for vectorized parameters
Model alternatives should not be contained in the same module
Complex Data Objects
Complex data objects should be constructed as dictionary representations
Dictionary keys shall contain readable, short, descriptive strings for data. Where appropriate, names will be followed by units such as ‘acceleration (m^2/s)’
Multiword descriptions will be separated by space rather than camel case
Operations on complex data do not necessarily recognize derivative units, scientific prefixes, or permutations of units
Preferred Unit Keys
Description |
Key |
|---|---|
Ion energy |
|
Linear energy transfer |
|
Ion isotropic differential flux spectra |
|
Neutron directional differential flux spectra |
|
Isotropic integral LET spectra |
|
Preferred Particle Keys
Description |
Key |
|---|---|
Ion |
<atomic number> |
Neutron |
|
Electron |
|
Data Format for Particle Spectra
Particle flux spectra will be represented by a an array of independent values, and a dictionary of dependent values keyed by particle types
{
'Energy (MeV/n)': [ 1.00000000e-01, 1.01389739e-01, 1.02798792e-01, ... ],
'Flux (/cm^2-s-sr-(MeV/n)': {
'1': [ 1.4765E+05, 1.4808E+05, 1.4852E+05, ... ],
'2': [ 3.8999E+03, 3.8952E+03, 3.8899E+03, ... ],
}
}
Integral LET spectra will be represented by a an array of independent values, and a dictionary of dependent values keyed by particle types
{
'LET (MeV-cm^2/mg)': [ 1.0, 3.0, 10.0, ... ],
'Flux (/cm^2-s-sr)': {
'1': [ 1.4765E+05, 1.4808E+05, 1.4852E+05, ... ],
'2': [ 3.8999E+03, 3.8952E+03, 3.8899E+03, ... ],
}
}