.. _lbroadmap:

Lionbolt
========

.. attention:: This page is WIP.

.. 1. General API Cleanup & Optimization
.. -------------------------------------
    
..     Cleaning up API, in particular, output file and writing. Lionbolt internal AND public API routines are littered with write statements, that were initially placed when Lionbolt was intended to be used solely as a program. This needs a rather significant (and tedious) overhaul, ideally without actually touching the resultant output file in the 'main' solution sequence.
    
..     Furthermore, Lionbolt was not aggressively optimized/benchmarked in the first release. Storage and computation speed should both be improved.
    
.. 2. Custom Physics Input
.. -----------------------
    
..     At the moment, users may only use physics generated by NittanyPhysics. This will certainly be changed in the future.
    
.. 3. MPI Implementation
.. ---------------------
    
..     Implement MPI for more optimized use of Lionbolt in HPC clusters, beyond previously-implemented OpenMP.
    
.. 4. Mesh Update 1
.. ----------------
    
..     An overhaul of the MeshClass type, to make mesh objects much more sophisticated. The details are currently being contemplated, but likely, the linkage of elements to one another via pointers, the development of various type-bound procedures such as a refinement routine, the binding of inner products to elements rather than a separate object, etc. Furthermore, and very importantly, the ability to work with concave geometries, as well as geometries with cavities or empty space. This will likely entail a small rewrite to the transport operator and sweep routines.
    
..     To facilitate all of these, it is likely that Lionbolt will be given the capability to create an 'octree,' similar to what Terpdose already has for the purpose of finite element interpolation.
    
..     It is also possible that rather than rewrite the MeshClass type, Lionbolt will be linked to a finite element analysis library. It remains to be decided.
    
.. 5. Sources Update 1
.. -------------------
    
..     A series of tweaks/additions to the way that external beams are handled. Some planned features:
    
..     - *User-defined beam angular/area distribution* The user can provide the distribution of fluence as a function of the angle cosine (for spherical sources) or azimuth (for planar sources) about the source origin.
..     - *Automatic mesh refinement inside of the beam* The user-defined mesh can be refined, at least in the path of a beam, according to the optical path length of source particles inside of a given mesh element.
..     - *Automatic definition of a beam's profile inside of the user's mesh* The user-defined mesh can have an outline of their beams defined by Lionbolt (and saved to output).
    
.. 6. Spherical Harmonics (PN) Implementation
.. ------------------------------------------
    
..     Implementation of the PN angular discretization method :cite:`Battista2019, Demaziere`. Typically, one could say that the largest obstacle in implementing something like this would be evaluation of the FEM inner products, which now are closely tied to expressions involving spherical harmonics. However, in the process of writing wiscobolt, expressions for these inner products both analytically and via quadrature have been derived. Thus, the primary obstacle for Lionbolt would be seamlessly weaving PN into the operator structure that was originally created with SN in focus. Optimization, in both memory and computation time, is also going to take a while.
    
.. 7. Sources Update 2
.. -------------------
    
..     A second round of additions to the way that sources are defined. Some planned features:
    
..     - *User-defined beam cutouts* The user can essentially collimate their beam beyond just ellipses and rectangles. Now, they can provide parametric coordinates OR a parametric equation with a number of increments, specifying a closed loop (in addition to the location along the beam axis at which the loop is defined) that will serve as their beam cutout.
..     - *Internal sources* I'm not fully sure how I'd implement these to actually be useful. Among the ideas I have, allowing the user to provide an HDF5 file containing phase-space source data or a spatial distribution of a later-specified source (such as corresponds to a given radionuclide), or simple geometric sources that can all be defined in the input file.

.. .. bibliography::    :filter: docname in docnames    :style: unsrt