Giter VIP home page Giter VIP logo

feelpp / feelpp Goto Github PK

View Code? Open in Web Editor NEW
293.0 49.0 66.0 332.59 MB

:gem: Feel++: Finite Element Embedded Language and Library in C++

Home Page: https://docs.feelpp.org

License: GNU Lesser General Public License v3.0

Smarty 0.01% C++ 79.56% Python 1.52% CMake 5.07% MATLAB 0.07% C 4.97% GLSL 1.47% JavaScript 0.65% TeX 0.94% Shell 2.58% CSS 0.01% Makefile 1.38% HTML 0.07% LLVM 0.01% Tcl 1.23% Emacs Lisp 0.02% Yacc 0.07% M4 0.28% Roff 0.07% Ruby 0.02%
c-plus-plus high-performance-computing parallel-computing finite-elements high-order reduced-basis scientific-computing multiphysics object-oriented metaprogramming

feelpp's Introduction

Feel++: Finite Element Embedded Library in C++

feelpp DOI

feelpp?color=009688&logo=Riseup&style=flat square feelpp?color=009688&logo=Moleculer&logoColor=white&style=flat square feelpp?color=009688&logo=Bilibili&logoColor=white&style=flat square feelpp?logo=Draugiem feelpp?color=009688&style=flat square&logo=Hack The Box&logoColor=white

Feel++ is a C++ library for continuous or discontinuous Galerkin methods including finite element method(FEM), spectral element methods(SEM), reduced basis methods, discontinuous galerkin methods (DG and HDG) in 1D 2D and 3D and in parallel. Checkout What is Feel++?, Feel++ Features and some Examples.

Releases

The latest release of Feel++ is here feelpp

Feel++ has a DOI provided by Zenodo. Please use this to cite Feel++ if you use it in a publication DOI

Feel++ is split into three components:

feelpp

library and tools

feelpp-toolboxes

mono and multiphysics toolboxes (cfd, csm, heat transfer, fsi, heat and fluid, hdg(poisson and elasticity), thermo-electric and maxwell)

feelpp-mor

model order reduction applications and tools

These components are built and delivered in two distribution channels: stable and latest. The channels are currently available via Docker containers, Debian and Ubuntu packages.

stable

Once a year, sometimes more, we make a release of Feel++ and it becomes the basis of the stable channel. The channel is updated infrequently, only for a new release or a major bug.

latest

Feel++ has a very active development and changes are made everyday with the research done by Cemosis and its collaborators. Each commit in the main development branch triggers a new full build with more than 800 tests from unit test to full pde solves.

Instructions are available here to install Feel++ : https://docs.feelpp.org/user/latest/install/index.html.

Feel++ Documentation

Slack Discussion Forum

We encourage you to ask questions and discuss any aspects of the project on Slack. New contributors are always welcome!

Continuous Integration

Feel++ maintains various branches. At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime: master and develop

master

Main branch where the source code of HEAD always reflects a production-ready state.

develop

Main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

feature/*

Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).

What is Feel++?

Feel++ is a C++ library for continuous or discontinuous Galerkin methods including finite element method(FEM), spectral element methods(SEM), reduced basis methods, discontinuous Galerkin methods (DG and HDG) in 1D 2D and 3D and in parallel. The objectives of this framework are quite ambitious; ambitions which could be expressed in various ways such as :

  • the creation of a versatile mathematical kernel solving easily problems using different techniques thus allowing testing and comparing methods, e.g. cG versus dG,

  • the creation of a small and manageable library which shall nevertheless encompass a wide range of numerical methods and techniques,

  • build mathematical software that follows closely the mathematical abstractions associated with partial differential equations (PDE),

  • the creation of a library entirely in C++ allowing to create complex and typically multi-physics applications such as fluid-structure interaction or mass transport in haemodynamic.

Features

  • 1D 2D and 3D (including high order) geometries and also lower topological dimension 1D(curve) in 2D and 3D or 2D(surface) in 3D

  • continuous and discontinuous (dG and hdG) arbitrary order Galerkin Methods in 1D, 2D and 3D including finite and spectral element methods

  • domain specific embedded language in C++ for variational formulations

  • interfaced with PETSc for linear and non-linear solvers

  • seamless parallel computations using PETSc

  • interfaced with SLEPc for large-scale sparse standard and generalized eigenvalue solvers

  • supports Gmsh for mesh generation

  • supports Gmsh for post-processing (including on high order geometries)

  • supports Paraview and CEI/Ensight for post-processing and the following file formats: ensight gold, gmsh, xdmf.

Contributing

In the spirit of free software, everyone is encouraged to help improve this project. If you discover errors or omissions in the source code, documentation, or website content, please don’t hesitate to submit an issue or open a pull request with a fix. New contributors are always welcome!

Here are some ways you can contribute:

  • by using develop versions

  • by reporting bugs

  • by suggesting new features

  • by writing or editing documentation

  • by writing specifications

  • by writing code — No patch is too small.

    • fix typos

    • add comments

    • write examples!

    • write tests!

  • by refactoring code

  • by fixing issues

  • by reviewing Pull Requests

The Contributing guide provides information on how to create, style, and submit issues, feature requests, code, and documentation to the Feel++ Project.

Getting Help

The Feel++ project is developed to help you easily do (i) modelisation simulation and optimisation and (ii) high performance computing. But we can’t do it without your feedback! We encourage you to ask questions and discuss any aspects of the project on the discussion list, on Twitter or in the chat room.

Twitter

#feelpp hashtag or @feelpp mention

Chat (Slack)

Slack

Further information and documentation about Feel++ can be found on the project’s website.

Home | News | Docs

The Feel++ organization on GitHub hosts the project’s source code, issue tracker, and sub-projects.

Source repository (git)

https://github.com/feelpp/feelpp

Issue tracker

https://github.com/feelpp/feelpp/issues

Feel++ organization on GitHub

https://github.com/feelpp

Copyright © 2011-2023 Feel++ Consortium. Free use of this software is granted under the terms of the GPL License.

See the LICENSE file for details.

Authors

Feel++ is led by Christophe Prud’homme and has received contributions from many other individuals.

Examples

Laplacian in 2D using P3 Lagrange basis functions

Here is a full example to solve

-\Delta u = f \mbox{ in } \Omega,\quad u=g \mbox{ on } \partial \Omega

#include <feel/feel.hpp>

int main(int argc, char**argv )
{
    using namespace Feel;
    Environment env( _argc=argc, _argv=argv,
                     _desc=feel_options(),
                     _about=about(_name="qs_laplacian",
                                  _author="Feel++ Consortium",
                                  _email="[email protected]"));

    auto mesh = unitSquare();
    auto Vh = Pch<1>( mesh );
    auto u = Vh->element();
    auto v = Vh->element();

    auto l = form1( _test=Vh );
    l = integrate(_range=elements(mesh),
                  _expr=id(v));

    auto a = form2( _trial=Vh, _test=Vh );
    a = integrate(_range=elements(mesh),
                  _expr=gradt(u)*trans(grad(v)) );
    a+=on(_range=boundaryfaces(mesh), _rhs=l, _element=u,
          _expr=constant(0.) );
    a.solve(_rhs=l,_solution=u);

    auto e = exporter( _mesh=mesh, _name="qs_laplacian" );
    e->add( "u", u );
    e->save();
    return 0;
}

Bratu equation in 2D

Here is a full non-linear example - the Bratu equation - to solve

\[-\Delta u + e^u = 0 \mbox{ in } \Omega,\quad u=0 \mbox{ on } \partial \Omega$$.\]
#include <feel/feel.hpp>

inline
Feel::po::options_description
makeOptions()
{
    Feel::po::options_description bratuoptions( "Bratu problem options" );
    bratuoptions.add_options()
    ( "lambda", Feel::po::value<double>()->default_value( 1 ),
                "exp() coefficient value for the Bratu problem" )
    ( "penalbc", Feel::po::value<double>()->default_value( 30 ),
                 "penalisation parameter for the weak boundary conditions" )
    ( "hsize", Feel::po::value<double>()->default_value( 0.1 ),
               "first h value to start convergence" )
    ( "export-matlab", "export matrix and vectors in matlab" )
    ;
    return bratuoptions.add( Feel::feel_options() );
}

/**
 * Bratu Problem
 *
 * solve \f$ -\Delta u + \lambda \exp(u) = 0, \quad u_\Gamma = 0\f$ on \f$\Omega\f$
 */
int
main( int argc, char** argv )
{

    using namespace Feel;
    Environment env( _argc=argc, _argv=argv,
                     _desc=makeOptions(),
                     _about=about(_name="bratu",
                                  _author="Christophe Prud'homme",
                                  _email="[email protected]"));
    auto mesh = unitSquare();
    auto Vh = Pch<3>( mesh );
    auto u = Vh->element();
    auto v = Vh->element();
    double penalbc = option(_name="penalbc").as<double>();
    double lambda = option(_name="lambda").as<double>();

    auto Jacobian = [=](const vector_ptrtype& X, sparse_matrix_ptrtype& J)
        {
            auto a = form2( _test=Vh, _trial=Vh, _matrix=J );
            a = integrate( elements( mesh ), gradt( u )*trans( grad( v ) ) );
            a += integrate( elements( mesh ), lambda*( exp( idv( u ) ) )*idt( u )*id( v ) );
            a += integrate( boundaryfaces( mesh ),
               ( - trans( id( v ) )*( gradt( u )*N() ) - trans( idt( u ) )*( grad( v )*N()  + penalbc*trans( idt( u ) )*id( v )/hFace() ) );
        };
    auto Residual = [=](const vector_ptrtype& X, vector_ptrtype& R)
        {
            auto u = Vh->element();
            u = *X;
            auto r = form1( _test=Vh, _vector=R );
            r = integrate( elements( mesh ), gradv( u )*trans( grad( v ) ) );
            r +=  integrate( elements( mesh ),  lambda*exp( idv( u ) )*id( v ) );
            r +=  integrate( boundaryfaces( mesh ),
               ( - trans( id( v ) )*( gradv( u )*N() ) - trans( idv( u ) )*( grad( v )*N() ) + penalbc*trans( idv( u ) )*id( v )/hFace() ) );
        };
    u.zero();
    backend()->nlSolver()->residual = Residual;
    backend()->nlSolver()->jacobian = Jacobian;
    backend()->nlSolve( _solution=u );

    auto e = exporter( _mesh=mesh );
    e->add( "u", u );
    e->save();
}

feelpp's People

Contributors

aancel avatar alixkien avatar asamake avatar cdaversin avatar clayrc avatar dbarbier avatar dependabot[bot] avatar doyeux avatar dprada85 avatar gdolle avatar ismailmo avatar jbwahl avatar lantzt avatar lberti avatar lsala avatar metivett avatar philippericka avatar prj- avatar prudhomm avatar ranine avatar romainhild avatar schenone avatar stephaneveys avatar thomas-saigre avatar trophime avatar vanthong avatar vhuber avatar vincentchabannes avatar vlceline avatar wkyoshe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

feelpp's Issues

failed to compile on ubuntu 12.04 gcc 4.6 with mpich2

Original author: [email protected] (May 02, 2012 08:39:30)

What steps will reproduce the problem?

  1. switch to mpich2
    2.
    3.

What is the expected output? What do you see instead?

feel++ should compile.
Instead we get an error :

/home/trophime/Projects/feel/trunk/feel/feelalg/matrixpetsc.hpp:49:12: erreur: using typedef-name �MPI_Win� after �struct�
/usr/include/mpich2/mpi.h:133:13: erreur: �MPI_Win� has a previous declaration here
make[2]: *** [feel/CMakeFiles/feel++.dir/options.cpp.o] Erreur 1

Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=21

Reorder dof with respect to interior, face, edge and vertex dof of the domain

For domain decomposition, we need to be able to manipulate the dof with respect to the topological entities of the domain:

  • interior dof
  • face dof
  • edge dof
  • vertex dof
    this is required for substructuring preconditioners

@feelpp/hamm this is for example necessary for the preconditioner for the mortar constraint formulation

fail to change hsize in geofile

Original author: [email protected] (April 24, 2012 15:26:25)

What steps will reproduce the problem?

  1. set hsize to 1.e-3 in a geofile
  2. set hsize to 0.1 in cfgfile
  3. run your feel++ app

What is the expected output? What do you see instead?

The hsize should be changed in the geofile in the repository

boost::regex is not working for this kind of hsize (xx.xxe-yy) in geofile
You can check this by adding :

Debug( 10000 ) << "found hsize: " << regex_search(__geo, regex, boost::match_default) << "\n";

in Gmsh::generateGeo(...) [feel/feelfilters/gmsh.cpp]

Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=19

failed to compile on ubuntu 12.04 gcc 4.6

Original author: [email protected] (September 19, 2012 11:26:38)

What steps will reproduce the problem?
1.update to latest rev
2.make

We end up with the following errors:

/home/trophime/Projects/feel/git/feelpp/feel/feelalg/solverlinearpetsc.cpp: In member function ‘void Feel::SolverLinearPetsc<T>::setPetscPreconditionerType()’:
/home/trophime/Projects/feel/git/feelpp/feel/feelalg/solverlinearpetsc.cpp:767:45: erreur: ‘PCGASM’ was not declared in this scope

This is certainly connected with the petsc version. Ubuntun 12.04 ships only 3.1 version :(

Original issue: http://code.google.com/p/feelpp/issues/detail?id=48

MPI errors with nlSolve function

Original author: [email protected] (March 21, 2012 09:50:21)

Issue using nlSolve (Newton algorithm with jacobian and residual parameters) :
M_backend->nlSolve(_jacobian=J, _solution=U_vec, _residual=R);

Even though the code is not compiled with mpi flag, execution gives the following error :

[euler:15691] *** An error occurred in MPI_Attr_get
[euler:15691] *** on a NULL communicator
[euler:15691] *** Unknown error
[euler:15691] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)

Original issue: http://code.google.com/p/feelpp/issues/detail?id=10

error when load an element_type from a database

Original author: [email protected] (June 30, 2012 14:18:12)

What steps will reproduce the problem?
See example in testsuite/feeldiscr/test_element_serialize

What is the expected output? What do you see instead?
Expected : to load an element_type from an existing database
Instead : std::logic_error: load function: invalid number of degrees of freedom ( from serialize in functionspace )

Please use labels and text to provide additional information.
Needed by CRB

Original issue: http://code.google.com/p/feelpp/issues/detail?id=41

gmsh - createGMSHMesh ( writting the .geo ) - problem with number of partition

Original author: [email protected] (September 02, 2012 08:35:34)

When using
mesh = createGMSHMesh ( _mesh = new mesh_type,
_desc = MyGeo( ),
_update=MESH_RENUMBER|MESH_UPDATE_EDGES|MESH_UPDATE_FACES|MESH_CHECK );
with

gmsh_ptrtype MyGeo()
{
std::ostringstream costr;
costr << "hs=" << meshSize << ";\n"
<< "Point(1) = {0, 0, 0, hs};\n"
[...]
}

I don't really understand why yet, but it will always give you a mesh with only one partition. However in generate function of Gmsh ( gmsh.cpp ) M_partitions has the correct value.
In order to have a mesh with the good number of partitions, you should add this number in your .geo file like :

gmsh_ptrtype MyGeo()
{
std::ostringstream costr;
int nb_partition = Environment::worldComm().globalSize();
costr <<" Mesh.NbPartitions=" << nb_partition << ";\n";
costr << "hs=" << meshSize << ";\n"
<< "Point(1) = {0, 0, 0, hs};\n"
[...]
}

Original issue: http://code.google.com/p/feelpp/issues/detail?id=47

Implement L_infinity norm

Original author: [email protected] (May 27, 2012 13:14:56)

the max norm for vectors is implemented but now we need to have
the L_infinity norms for functions (of function spaces).

The implementation will require evaluating the functions at quadrature nodes
(set automatically but that the user can actually change himself/herself).
and then compute the max of the evaluation.
We need not only to return the max absolute value but also the point coordinates in space at which it occurs

A boost.parameter interface is needed so that it is blends in nicely in the Feel++ language.

It is particularly useful for the EIM.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=29

Support for new Mesh operations (fusion)

Original author: [email protected] (June 30, 2012 16:31:15)

It would be nice to add these functionalities
1- sequential assembly even though the mesh is parallel (ie do only the local matrix assembly and no communication to create the full matrix
2- Fusion of two conforming meshes (or disjoing)
3- Fusion of a mesh with a pair of iterators on a list of elements
4- Fusion of a mesh with elements that share a face with an element of this mesh
5- Fusion of a mesh with elements that share an edge with an element of this mesh
6- Fusion of a mesh with elements that share a vertex with an element of this mesh
7- same things as fusion but the removal this time

Original issue: http://code.google.com/p/feelpp/issues/detail?id=42

Rounding errors in bdf metadata files

Original author: [email protected] (June 12, 2012 09:09:29)

What steps will reproduce the problem?

  1. BDF
    2.
    3.

Problem of rounded in metada files (bdf class)
22 serialization::archive 9 0 0 5695 0 0 0.00050000000000000001 0.001 0.0015 0.002 0.0025000000000000001 0.0030000000000000001 0.0035000000000000001 0.0040000000000000001 0.0045000000000000005 0.005000000000000001 0.0055000000000000014 0.0060000000000000019 0.0065000000000000023 0.0070000000000000027 ....

Original issue: http://code.google.com/p/feelpp/issues/detail?id=31

Wrong number of dof in parallel ?

Original author: [email protected] (August 07, 2012 08:32:07)

Hi

I wrote an e-mail on the mailing list but nobody received it, so I write here.

When running my code on two processors I have a problem when using the boost parameter function newMatrix from backendpetsc.
More precisely, to create the matrix, trial->nLocalDofWithoutGhost() and test->nLocalDofWithoutGhost() are used and it seems that my problem comes from here.

First of all I have a question :
If on proc 0 i have 476 dofs, and 480 dofs on proc 1, should i have :
test->nLocalDofWithoutGhost() = 476 ( proc 0 )
trial->nLocalDofWithoutGhost() = 476 ( proc 0 )
and
test->nLocalDofWithoutGhost() : 480 ( proc 1 )
trial->nLocalDofWithoutGhost() : 480 ( proc 1 )
?

Although on proc 0 these numbers are correct, but they are wrong on proc 1 because I get 465 instead of 480, so on proc 1 my matrix have a wrong size and it's annoying to perform matrix-vector multiplications...

Is anyone else have to deal with the same problem ?

Bests,

Original issue: http://code.google.com/p/feelpp/issues/detail?id=45

Implement new keywords det() and inv() in the variational formulation language

Original author: [email protected] (April 26, 2012 14:49:55)

Implement the keywords det and inv in the variational formulation language

  • det(matrix expression) : compute the determinant of the matrix expression
  • inv(matrix expression) : compute the inverse of the matrix expression

for example

integrate( elements(mesh), det(mat<2,2>( cst(1.), cst(0), cst(0), cst(1.0) ). evaluate() should produce the measure of the domain and det(mat<2,2>( cst(1.), cst(0), cst(0), cst(1.0) ) compute the determinant of the identity matrix 2x2

Original issue: http://code.google.com/p/feelpp/issues/detail?id=20

compilation issue with geo() interface

Original author: [email protected] (March 18, 2012 19:26:15)

What steps will reproduce the problem?

  1. compile loadmesh() using boost1.49

the problem is with the geo() free function interface, we ask depends to be a std::vector<std::string>
and it seems that program_options does not like that (might be a bug)
anyway this interface is not quite satisfactory: _depends should be string containing filenames which are separated by one of these characters ",;: " (including space)
then we use boost:string_algo to split the string into a std::vector<std::string> in geo()

Original issue: http://code.google.com/p/feelpp/issues/detail?id=9

trace or createSubmesh in parallel

Original author: [email protected] (March 28, 2012 16:49:11)

I meet a problem with trace and createSubmesh in parallel.
First we create our mesh M_mesh=createGMSHMesh(.., proc id) in parallel. Then

M_Xh = space_type::New( M_mesh, index ); // index is the proc id

auto sol = M_Xh->element();
auto trace_mesh = M_mesh->trace( markedfaces(M_mesh,1) );
auto Th = trace_space_type::New( trace_mesh );

auto t = vf::project( _space=Th, _range=elements(trace_mesh), _expr=vf::idv(sol) );

This calculation does not execute in parallel.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=13

Segfault in the language with g++ 4.7

Original author: [email protected] (May 20, 2012 10:54:55)

What steps will reproduce the problem?

  1. compile feel_doc_laplacian or feel_doc_myfunctionspace
  2. execute

It seems that with g++ 4.7 something is fishy with the code generation of Cst<>. Somehow when
evaluating expression (e.g. in project() ) they have become dangling references.
With gcc 4.5, 4.6 and clang 3.1, no problem. There is a good chance that this is a bug in g++ 4.7.
This is however very unfortunate because it makes 4.7 unusable for now.

This behavior is also consistent across platforms, ie. Linux and OSX.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=26

periodic boundary conditions do not compile for composite spaces

Original author: [email protected] (June 26, 2012 09:25:49)

What steps will reproduce the problem?

  1. Run the compilation of the test : fsi/application/levelset/periodic_composite

It seems that for every subspaces of the function space, the code enters in a constuctors which doesn't give the information of the periodicity but only the dofindices. Then it gives as defaut periodicity object : "NoPeriodic()"

Original issue: http://code.google.com/p/feelpp/issues/detail?id=38

OpInterlation too slow

Original author: [email protected] (March 12, 2012 16:00:02)

What steps will reproduce the problem?

  1. nirb
    2.
    3.

What is the expected output? What do you see instead?

Please use labels and text to provide additional information.

J'ai remarqué que la construction de l'opérateur "opInterpolation" prenait parfois beaucoup de temps, beaucoup plus que l'appel de "interpolate". Je me demandais si c'était normal ou si c'était une mauvaise utilisation de ma part.

Dans la version que je viens de "commiter" j'ai commenté la partie qui appelle "opInterpolate" pour utiliser "interpolante", car au final ça reste plus rapide d'appeler (N+1) fois 'interpolate', que de construire 2 fois l'opérateur.

Au premier appel de l'opérateur "opInterpolate", la construction de celui-ci prend très longtemps (plus 210sec) contre 4sec pour l'appel d'interpolate.
Par contre au second appel, la construction de l'opérateur est beaucoup plus rapide à peine quelques secondes.

Voici les 2 routines pour lesquels j'ai besoin de faire l'interpolation du maillage grossier vers fin, si jamais vous voulez regarder.

element_type :BuildCoarseInterpolation(space_ptrtype XhFine,space_ptrtype XhCoarse, double param);
Eigen::MatrixXd BuildBetaH(space_ptrtype XhFine,space_ptrtype XhCoarse,vector_of_element_type &M_VNirbBasis);

En attendant je vais refaire les test en construisant directement la matrice correspondant à la forme bilinéaire (uHGrossier, vhFin), voir si ça donne toujours des résultats bizarre ou non, dans quel cas il n'y aurais plus besoin de passer par l'interpolée.

Original issue: http://code.google.com/p/feelpp/issues/detail?id=3

problem with dot function in parallel when using vectors

Original author: [email protected] (August 30, 2012 19:53:25)

Using vectors, the dot function provides bad results in // while results are good when using element_type
For example if Xh is the function space :

auto v1 = backend->newVector( Xh );
auto v2 = backend->newVector( Xh );
[do operations ....]
v1->close(); v2->close();
dot( *v1 , *v2 ); // wrong result

element_ptrtype ev1 ( new element_type ( Xh ) );
element_ptrtype ev2 ( new element_type ( Xh ) );
*ev1 = *v1;
*ev2 = *v2;
dot( *ev1 , *ev2 );// good result (and same result than in sequential)

Original issue: http://code.google.com/p/feelpp/issues/detail?id=46

specify python version on cdash

Original author: [email protected] (May 15, 2012 12:53:44)

Openturns 0.1 cannot be build with python 3.2
It has been build with python 2.7.

(for Debian see: https://github.com/dbarbier/deb-ot
and Bug#670066)

On machines with python 3.xx installed it would be nice
to specify python version in cmake to avoid potential
problem with Openturns.

Adding the following lines to cmake command line do the trick:

-DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python
-DPYTHON_INCLUDE_DIR:PATH=/usr/include/python2.7
-DPYTHON_LIBRARY:PATH=/usr/lib/python2.7/config/libpython2.7.so

Original issue: http://code.google.com/p/feelpp/issues/detail?id=25

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.