jayjaybillings / fire Goto Github PK

The current implementation of LocalParser<std::vector>::parse() (which hasn't been pushed yet) works, but needs to be updated to either read the whole file and work in memory or to use streams. It also needs to be updated to support comments in the file.

The current code is Mike's initial implementation in FERN for his GPU test code.

Running CMake 3.6.2 (which is the default now in Fedora 25 when you run dnf install cmake) fails with

-- MAGMA support requested. Searching at MAGMA_ROOT=.
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") 
-- Checking for one of the modules 'magma;magma_sparse'
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:646 (message):
  None of the required 'magma;magma_sparse' found
Call Stack (most recent call first):
  cmake/Modules/FindMAGMA.cmake:61 (pkg_search_module)
  solvers/CMakeLists.txt:54 (find_package)

when the user does not have MAGMA installed. Later versions of CMake prefer

if (MAGMA_ROOT) (works for 3.6.2)

instead of

if (NOT MAGMA_ROOT STREQUAL "") (does not work for 3.6.2)

These files can and usually do contain information that is specific to the users Eclipse workspace, making them not very portable and always show up as changed files in the Git Staging view.

I propose we remove them from the repo. Any objections @jayjaybillings ?

Parsing is kind of dirty right now. It can be done in a stereotypically annoying way

LocalParser<T> parser;
parser.setSource(fileName);
parser.parse();
shared_ptr<T> myData = parser.getData();

or a shorter but more confusing way

auto parser = build<LocalParser<vector<T>>, const string &>(fileName);
auto myData = speciesParser.getData();

What I would like to have is something like

auto myData = parse<T>(filename);

Is it possible to add me as an admin on this project? That way I could go in and configure the travis stuff.

We need to create a tutorial for working with Ganjiang in the Fire Docs folder and hook the new source folder up to the Doxygen scanner once PR #23 is accepted. @dgquvn

We need a tool that lets us execute HTTP GET and POST commands. We need this for real-time updates from simulations to ICE. We also need this for XACC Rigetti QPU support.

The header file names for Tensor should be .h, not .hpp.

I need to thoroughly review and possibly rewrite much of the memory model documentation in the docs/_posts directory. I am also considering a different way of handling memory allocation anyway and that needs to be noted.

@jayjaybillings

When you get a chance, will you go into the Settings > Integration and Services and add Travis CI as a service for this project? I just made a commit that will set that up to run a build and test on Fedora 25 and Ubuntu 16.04 every time we push to master.

Could I used templated parsers instead of subclasses? That would certainly simplify things.

Based on the code from Fire, the Reaction struct will start out with arrays of reactant Z, N and A values instead of links to actual species classes. This should be corrected so that the reactions depend directly on lists of species which store that data instead of duplicating it and convoluting it in separate arrays.

This will require making the list of Species searchable by Z, N and A.

Add MAGMA to the build and develop some solver interfaces.

The Fire API Documentation section on Readthedocs is messed up and should be fixed. Most likely the contents.rst or conf.py file is messed up.

I think I need a unit test for parse(). Other unit tests are using it, but it should probably be covered like build() and the string splitting routines.

I have made a bunch of header files dirty by adding "using namespace std." I need to remove that.

Add a markdown document discussing the architecture and use Fire's new Tensor support.

We need to be able to put references in the Jekyll documentation, so we should add support for Jekyll Scholar as described at http://www.rubydoc.info/gems/jekyll-scholar/0.0.12

I was messing around with State in the fem branch this morning, trying to remove the need to keep a shared_ptr internally to store a pointer to T. I was able to do that using explicit move semantics, but that caused some interesting - although repairable - problems with the parts of the class that uses pointers.

I think I have some ideas on how to remove pointers from the API and still use them internally. Pointers are only there for the purpose of connecting to C-based solvers. I think I can internalize this with link() and unlink() operations that do some pointer trickery without exposing the pointers on the API.

The ReactionNetwork::buildFluxMaps() operation needs to be refactored. It is based on the original routine from FERN. It is all sorts of mangled and tangled.

The memory model documentation needs a C++ example for how to use data arrays. I just put a stub in there for now.

We shouldn't have Ganjiang's pycache stored in the repo. It should be deleted and added to .gitignore.

There are several key variables in the new reaction class that have little or no documentation. You should review the documentation with Mike to figure out what needs to be captured.

Picking points from the solid geometry in OCC is far slower than a tree implementation. Look at doing this with CGAL instead using a tree of axis-aligned bounding boxes and randomly sampled points. The complexity should drop from N_points*M_faces to log(N_boxes).

Build fails in master if building from README instructions. Pulling down Fire and running cmake and make results in

In file included from /projects/test/fire/astrophysics/tests/NetworkIntegrationTest.cpp:40:0:
/projects/test/fire/solvers/ODESolver.h:35:36: fatal error: nvector/nvector_serial.h: No such file or directory
 #include <nvector/nvector_serial.h>
                                    ^
compilation terminated.

Are SUNDIALS/BLAS/LAPACK now required dependencies?