Public Articles
Solar powered electrical microgrids in urban environments
and 1 collaborator
Most Systematic reviews of high methodological quality on psoriasis interventions are classified as high risk of bias using ROBIS tool.
and 3 collaborators
Plataforma en la nube
Abstracto– El concepto de “nube informática” es muy amplio y abarca casi todos los posibles tipo de servicio en línea pero cuando las empresas predican ofrecer un utilitario alojado en la Nube por lo general se refieren a alguna de estas tres modalidades: el software como servicio (por sus siglas en inglés SaaS –Software as a Service-),Plataforma como Servicio (PaaS) e Infraestructura como Servicio (IaaS).
Title
Title
asdf
$$\\$$
$$ v_{t+1} = v_t e^{\alpha_t (RT_t - T^{G/S}) } $$
$$\\$$
$$\pi_t = \begin{cases} \left (\frac{t}{10} \right)^p, & \text{if stop trial}\\1, & \text{if go trial}\end{cases}$$
$$\\$$
$$ \alpha_t = \pi_t \alpha_0 $$
$$\\$$
$$ \beta_t = \pi_t \beta_0 $$
$$\\$$
$$z_{t_{err}} = z_0 + \beta_t e^{-t_{err}}$$
$$\\$$
$$\chi^2_{adapt} = \sum_{i}^{30} w_{acc,i}(\mu_{acc,i} - \hat{\mu}_{acc,i})^2 + \sum_{i}^{30} w_{rt,i}(\mu_{rt,i} - \hat{\mu}_{rt,i})^2$$
$$\\$$
$$\chi^2_{static} = w_g (P_g - \hat{P_g})^2 + \sum_d^5 w_d(P_d - \hat{P_d})^2 + \sum_q^9 w^C_q (RT^C_q - \hat{RT^C_q})^2 + \sum_q^9 w^E_q (RT^E_q - \hat{RT^E_q})^2$$
$$\\$$
proyecto
Accurate Complementary WIP System for Foot Placement in VR Using Motion Controllers
Optimally Matching Children to Foster Families and Debunking the Myths of NYC Foster Care
and 4 collaborators
Kapala Tools Feedback and Suggestions
Creating CDI data for BLM QA
Mühlengeschichte im Wildecker Tal
Simulation of very severe cyclone Huhdud using a high resolution WRF-ARW model: Sensitivity to the Physics parameterization and initial conditions
and 1 collaborator
Genotoype-by-sequencing of three geographically-distinct populations of the Olympia oyster, Ostrea lurida
and 1 collaborator
The Differential Cross Section of High Energy Gamma Rays with Compton Scattering
and 1 collaborator
PCMSolver Discussion
and 3 collaborators
This list doesn’t assume any specific priority for the various items. I
give some background and an evaluation (personal) of difficulty level
(0: easily implemented; 5: major effort) with (perceived) motivation and
challenges.
Removal of Boost. It has become a significant annoyance.
PCMSolver already uses only the headers, but to satisfy smoothly
this dependency we have to jump through some hoops. Some features
are now provided by the new standard. Some critical portions of
our code depend, however, on functionanilty provided by Boost: MPL
(metaprogamming library) and Odeint (for integrating the diffuse
interfaces ODEs) Difficulty level: 2, because finding replacements
for MPL and Odeint might not be a walk in the park.
Input parameter passing Get rid of GetKw, use a standard format
like YAML, unify the host-side and API-side input reading (that
is, allow the host to implement our input parameters as part of
their input file and pass it through the API) Difficulty level: 4,
because is boring to think about input format and information
sharing and also because every mechanism has to be compatible with
Fortran (a royal pain) and C.
C++11 and later It’s 2017, bye bye C++03 compliance. Difficulty
level: 1, I did it on a fork some time ago.
CMake 3.3 It’s 2017, bye bye CMake 2.8. Difficulty level: 1, I
did it on a fork some time ago.
Expose a proper Python module It would be awesome to be able to
run tests using Python instead of waiting ages for the unit test
executables to compile and link. Difficulty level: 5, because it
requires studying extensively the way Psi4 did it.
Autogeneration of API files The API is defined in a C++ class,
whose methods get then exposed in a C API, that is optionally
wrapped by a Fortran module (for type safety in Fortran). Both the
C and Fortan API can be autogenerated. Difficulty level: 4,
because I know nothing about automatic code generation.
Binary distribution Instead of telling people “here’s the code,
go compile it” we could just tell “here’s the pre-compiled
library, download it” It can’t currently be done because, guess
what, Fortran modules are not a good format to distribute APIs. If
we get over this annoyance, then the infrastructure is already in
place thanks to the work of Lori Burns. Difficulty level: 3,
because there’s some infrastructure to be put in place. This point
also depends on the autogeneration of API files
Nonelectrostatic contributions We need to think about the API
for these and how to accommodate them internally. My
suggestion is to organize the code around the concept of
“interactions”, each interaction returns an energy and is
initialized by a computational backend. For electrostatics the
computational backend would be the combination of cavity, Green’s
functions and solver. No difficulty level attached, since we need
to discuss the architecture of this before breaking it down into
tasks.
ddCOSMO/ddPCM The domain decomposition code is very attractive
and open source (LGPL) We can include it as an additional solver
within PCMSolver. The code is Fortran, uses an hand-written
Makefile, has no tests. I would say a first step here is to
CMake-ify the code and rework the example as a test. We can then
interface.
Spherical and planar interfaces, both diffuse and sharp We have
the spherical diffuse. Luca did the planar diffuse, but never
merged back. I did some stuff on the spherical and planar sharp,
but never finalized the tests. These can and should be finalized
and released. Difficulty level: 3, because it hinges on finding a
replacement for Odeint. Luca found that Runge-Kutta-Fehlberg 7(8)
worked fine for planar diffuse and it would probably work fine for
spherical diffuse too. If that’s the case, we can ditch Odeint and
reimplement RFK78 internally
(https://github.com/zhengfaxiang/Runge-Kutta-Fehlberg/blob/master/include/rkf78.hpp)
Complex permittivities Relevant for spherical sharp interfaces,
mostly. Possible collaboration with Stefano. Difficulty level: 3,
because I haven’t quite figured out the testing.
Time-dependent solvers I think we can release these already in
v1.2.0, despite the fact that we don’t have a publication in
tandem with ReSpect.
TsLess cavity This was work with Cris, he never delivered,
unfortunately. The current status is a branch where we can obtain
cavities that make sense and. Some testing for energies (within
LSDALTON or Psi4) against the results in his paper
(10.1002/jcc.20076) and this is good to go. Difficulty level: 2,
because we need to test and because we probably need to ask Cris
permission to release (though he gave us the code himself)
Gradients for GePol and TsLess We should take this top-down,
that is, figure how should the API to communicate the PCM parts of
the gradient look like and then patch the pieces layer by layer
all the way down to the cavity generator. I would start with
TsLess, given that the formulas in Cris’ paper look easy to
implement. Difficulty level: 4, but probably it’s a 5
Wavelet code Bring it back into the fold and release it, so we
don’t lose it in the meander of dead branches. Difficulty level:
3, because the merge will be a pain.
Relicensing under MPL2.0 This license imposes less restrictions
on redistribution, but I need to read more about it
http://www.oreilly.com/openbook/osfreesoft/book/ch03.pdf
The license discussion can be taken another day.
Formalization of a contributor license agreement
Classes to handle classical point multipole distributions This
is probably useful in the perspective of implementing QM/MM/PCM or
QM/PCM/MM Difficulty level: 3, because I know how to do it up to
dipoles, but I would like something open-ended and that can handle
both cartesian and spherical.
Checkpoint/restart capabilities Save cavities, solvers etc for
later reuse or restart. Difficulty level: 3, we can dump to numpy
format.
Threading Consider a clean way to enable threading in Eigen
without wreaking havoc in the host progam. Difficulty: 3, because
I don’t know how to do it, but I don’t expect it to be ultrahard.
Eigen and BLAS/LAPACK backends (MKL, ATLAS…) Eigen can now
offload operations to F77 BLAS/LAPACK backends
http://eigen.tuxfamily.org/dox-devel/TopicUsingBlasLapack.html
I would like to have the possibility to optionally enable this
feature. This means bringing back CMake math detection. Difficulty
level: 3, because of the math detection.
Dimensional analysis It would be good to have quantities to
track their physical dimension and automagically convert
themselves when necessary. This can be done in C++11
https://github.com/nholthaus/units
https://github.com/martinmoene/PhysUnits-CT-Cpp11
And also in Python
https://github.com/sbyrnes321/numericalunits
https://github.com/hgrecco/pint
https://github.com/tbekolay/quantities-comparison
Difficulty level: 3, because there’s a need to go through the docs
for these libraries and because this is a rather fundamental
change in how stuff in handled internally.
Smarter vector and matrices, capable of tracking symmetry
information Vectors/matrices are now “bare” objects with no info
whatsoever on symmetry. Result is that symmetry manipulations
require a lot of boilerplate. Difficulty level: 5, because I tried
extending Eigen data structures and failed. I need help with the
design of what the smart versions should be able to do.
Local field effects We have done no work here. I don’t know
exactly what’s expected of PCMSolver.
Repo maintenance stuff with no difficulty level assessment:
Integration with Danger systems
Various CI improvements (Travis, Drone, AppVeyor)
Restoring code coverage count
Restoring static analysis on Coverity
Investigate static analysis tool clang-tidy
Foster Care Design Challenge Submission
and 2 collaborators
Reverse Network Inference
and 1 collaborator
Welcome to Authorea!
TAGNITHAMMOU TAFSUT
The studied article is titled “Multiclass Brain-Computer Interface Classification by Riemannian Geometry”. It was published on 21 March 2012, by the Institute of Electrical and Electronics Engineers (IEEE) Transaction on biomedical journal. IEEE is the world’s largest technical professional organization, dedicated to advancing technology for the benefit of humanity. It publishes the leading journals, transactions, letters and magazines in electrical engineering, computing, biotechnology, power, telecommunications and other technologies. The article is written by Alexandre Barachant, Stéphane Bonnet, Marco Congedo, and Christian Jutten.
Alexandre Barachant is a postdoctoral research follow in Burke-Cornell Medical Research Institute from New York. Stéphane Bonnet is working for CEA LETI in Grenoble . Marco Congedo is for CNRS. And Christian Jutten is a professor at University of Grenoble, and institut Universitaire de France (IUF).
The authors had presented, in this article, two new methods using Riemannian Geometry, to classify the BCIs applications based on Motor Imagery (MI). First, it introduces by presenting the classical method to do a classification of BCIs applications using the spatial filters. Then, it explains the use of covariance matrices in BCI. Obviously we have a short introduction of the Riemannian Geometry. Next, the two methods and the algorithms used are well explained, the Minimum Distance to Riemannian Mean (MDRM) and the Tangent Space Mapping (TSLDA). Then, we had some figures to illustrate the different results obtained using the two method of classification. Finally, it concludes by focusing on the advantages and constraints of the two methods, and presented the different issues for further theories and improvements. The study of the article is made of several parts, first in the introduction, a short presentation of the different authors, the journal and the idea of the article. Then, the background of the article. Next, a short state-of-the-art and the different contributions of the method are presented. I conclude by giving a short contrast about the article; contributions and further improvement and inconvenient.