faq

The Free Finite Element Package is a library which contains numerical methods required when working

                          Free Finite Element Package

-------------------------------------------------------------------------------


                                     FF AA QQ


* _I_s_ _t_h_e_ _l_i_b_r_a_r_y_ _r_e_a_d_y_ _f_o_r_ _u_s_e_?
* _W_h_i_c_h_ _d_e_p_e_n_d_e_n_c_i_e_s_ _d_o_e_s_ _F_F_E_P_ _h_a_v_e_?
* _I_ _a_m_ _o_n_l_y_ _i_n_t_e_r_e_s_t_e_d_ _i_n_ _o_n_e_ _m_o_d_u_l_e_._ _C_a_n_ _I_ _u_s_e_ _i_t_ _w_i_t_h_o_u_t_ _t_h_e_ _r_e_s_t_ _o_f_ _F_F_E_P_?
* _I_s_ _t_h_e_r_e_ _a_ _p_o_r_t_ _o_f_ _F_F_E_P_ _t_o_ _M_a_c_,_ _W_i_n_d_o_w_s_ _._._._ _?
* _L_i_c_e_n_s_i_n_g
* _W_h_y_ _i_s_ _F_F_E_P_ _w_r_i_t_t_e_n_ _i_n_ _C_ _?
* _W_h_y_ _d_i_d_ _y_o_u_ _w_r_i_t_e_ _M_E_M_L_ _a_n_d_ _d_i_d_ _n_o_t_ _u_s_e_ _a_n_ _e_x_i_s_t_i_n_g_ _l_i_b_r_a_r_y_ _l_i_k_e_ _._._._ _?
* _A_r_e_ _t_h_e_r_e_ _a_n_y_ _o_t_h_e_r_ _l_a_n_g_u_a_g_e_ _b_i_n_d_i_n_g_s_?
* _W_h_i_c_h_ _s_y_s_t_e_m_ _i_s_ _u_s_e_d_ _f_o_r_ _t_h_e_ _v_e_r_s_i_o_n_ _n_u_m_b_e_r_i_n_g_?
* _W_h_y_ _i_s_ _f_o_o_ _n_o_t_ _i_m_p_l_e_m_e_n_t_e_d_?
* _W_i_l_l_ _f_o_o_ _b_e_ _i_m_p_l_e_m_e_n_t_e_d_ _s_o_m_e_ _d_a_y_?
* _H_o_w_ _c_a_n_ _I_ _h_e_l_p_?
* _I_ _h_a_v_e_ _p_r_o_g_r_a_m_m_e_d_ _a_ _f_u_n_c_t_i_o_n_ _o_r_ _m_o_d_u_l_e_ _w_h_i_c_h_ _i_s_ _b_a_s_e_d_ _o_n_ _M_E_M_L_/_F_F_E_P_,_ _b_u_t_ _i_t
  _h_a_s_ _n_o_t_h_i_n_g_ _t_o_ _d_o_ _w_i_t_h_ _F_i_n_i_t_e_ _E_l_e_m_e_n_t_s_ _._._.

-------------------------------------------------------------------------------

IIss tthhee lliibbrraarryy rreeaaddyy ffoorr uussee??

 Mostly : YYeess.
But it is still a beta-version so you might miss some features and not every
part of the library is as optimized as possible.
-------------------------------------------------------------------------------

WWhhiicchh ddeeppeennddeenncciieess ddooeess FFFFEEPP hhaavvee??

 FFEP requires:

* a C compiler which is compatible to C99, like gcc 3.x. Most compilers that
  can handle C89/ANSI C and provide the use of 'inline' should also work.
* cblas/atlas
* lapack
* f2c

-------------------------------------------------------------------------------

II aamm oonnllyy iinntteerreesstteedd iinn oonnee mmoodduullee.. CCaann II uussee iitt wwiitthhoouutt tthhee rreesstt ooff FFFFEEPP??

 YYeess,,
but only the modules meml, meml + sesl and the hole ffep are setup with the
standard configure file. For the rest you have got to write a Makefile on your
own.
-------------------------------------------------------------------------------

IIss tthheerree aa ppoorrtt ooff FFFFEEPP ttoo MMaacc,, WWiinnddoowwss ...... ??

 NNoo, but everyone who wants to port FFEP to another operating system is
welcome.
It should be possible to port FFEP to any system that can fulfil the _d_e_p_s. If
you use windows, install _c_y_g_w_i_n first and after that all the software shown
under _d_e_p_s. That should work.
-------------------------------------------------------------------------------

LLiicceennssiinngg

 The licensing of FFEP pursues following targets:

* SSeett FFFFEEPP ttoo OOppeenn SSoouurrccee
  Science should have , if possible, Open Sources so that everyone can verify
  the published results. With Close Software tools and libraries it is
  impossible to fulfil this condition.
* GGPPLL CCoommppaattiibbllee LLiicceennsseess
  Most Open Source projects use GPL, so it would be a loss of utility to put
  FFEP under a GPL-incompatible Open Source License.
* NNoo ddiissccrriimmiinnaattiioonn ooff aannyy OOppeenn SSoouurrccee LLiicceennssee..
  A limitation to GNU Software should be prevented, so that every Open Source
  programmer is able to use FFEP.

Because of this FFEP will be covered by a BBSSDD--ssttyylleedd license. Some parts that
use external libraries or modules whose authors prefer this, might be covered
by LLGGPPLL. So a GGPPLL module can not be an official part of FFEP, but we would like
to link to its homepage.
-------------------------------------------------------------------------------

WWhhyy iiss FFFFEEPP wwrriitttteenn CC ??

 FFEP is written in C because of some reasons:

  1. C has a huge user-community, of course many people use C++ and not pure C,
     but they also can gain by the functionality of this library.
  2. C is a very small language. My K&R is a small book if I put it e.g. next
     to an entire C++ handbook. You are able to teach basic C in a few days to
     students with no programming experience, so that they can start working on
     numerical problems. I know from my own experience that dealing with
     pointers in combination with malloc, realloc etc. takes a little time, but
     some of these problems will hopefully be eliminated by using this library.
  3. And around a C library other languages can build wrappers, see for example
     the _G_T_K_+.
  4. C object-code is binary compatible between all compilers I know, like e.g.
     icc and gcc in contrast to C++.
  5. C is standardised by the International Organisation for Standardisation
     (ISO) and the American National Standards Institute (ANSI) and so highly
     portable, if it is written that it agrees on a standard; FFEP agrees to
     C99.

-------------------------------------------------------------------------------

WWhhyy ddiidd yyoouu wwrriittee MMEEMMLL aanndd ddiidd nnoott uussee aann eexxiissttiinngg lliibbrraarryy lliikkee ...... ??

 In fact MEML uses an existing library for dense matrix operations - CBLAS and
LAPACK. Both are highly qualified in speed and stability. MEML adds some
functions for memory-management and direct matrix-manipulation to CBLAS and
LAPACK.
In one of the future versions of MEML also the sparse matrix support for
sparse-blas will be included. Nevertheless, the sparse matrix functionality in
BLAS is not very extensive so that sparse-blas is not able to provide all the
needed functionality for MEML.
As you may know even this work has already been done. The library It++ provides
all this features, but it is written in C++ (see :_W_h_y_ _i_s_ _F_F_E_P_ _w_r_i_t_t_e_n_ _C).
There also exists the the GNU Scientific Library (GSL), which is written in C,
but does not have any support for sparse matrices.
So both libraries were not optimal for the goals of FFEP and both are released
under the terms of GPL (see _L_i_c_e_n_s_i_n_g for details).
-------------------------------------------------------------------------------

AArree tthheerree aannyy ootthheerr llaanngguuaaggee bbiinnddiinnggss??

 NNoo,, but technically it is possible. There aren't any plans for a C++ or
Pascal-Wrapper at the moment, in fact the lib itself is highly under
construction. But anyone who wants to start such a project is welcome.
-------------------------------------------------------------------------------

WWhhiicchh ssyysstteemm iiss uusseedd ffoorr tthhee vveerrssiioonn nnuummbbeerriinngg??

 FFEP starts with 00..11. With this version of the library it should be possible
to solve some problems and have basic matrix operations to support students in
numerical practice session.
If FFEP seems to be ready for use in real projects it will be version 11..00.
Everything in between we will figure out if the times comes...
In generell FFEP uses a very common system for version numbers : ...

The meaning of these terms is:
MMaajjoorr nnuummbbeerr Major release numbers are only changed when fairly large, sweeping
changes are made. The 0.x represents beta or alpha versions.
MMiinnoorr rreelleeaassee nnuummbbeerrss are changed with each official release. Even numbers
represent stable releases, while odd minor numbers are reserved for developer
releases.
UUppddaattee nnuummbbeerr; Update numbers are essential patches on a particular release.
For example, if errors are discovered, they will be eliminated. So, stable
updates are typically bug fixes or important system workarounds.
-------------------------------------------------------------------------------

WWhhyy iiss ffoooo nnoott iimmpplleemmeenntteedd??

 Because none of the FFEP developers has needed this function by now or has had
the time to implement it.
-------------------------------------------------------------------------------

WWiillll ffoooo bbee iimmpplleemmeenntteedd ssoommee ddaayy??

 Take a look at the to-do list. If it is listed there, there is a good chance
that it will become reality in a short time. If not, you can send a suggestion
to the mailinglist, and it might be added to the wish-list, so maybe someone
feels motivated and starts working.
In fact the FFEP developers are glad about good ideas but we are happier if
someone also sends the code to transform it into practice.
-------------------------------------------------------------------------------

HHooww ccaann II hheellpp??

 You can help in many ways:

* add functions or modules to FFEP, of course
* send bug-reports
* make FFEP easier to be installed on the system of your choice
* extend the tutorial
* translate the webpage and/or the tutorial into another language
* link this page, so that many people get to know about this project
* tell us, if you use FFEP. That can motivate us. :-)

-------------------------------------------------------------------------------

II hhaavvee pprrooggrraammmmeedd aa ffuunnccttiioonn oorr mmoodduullee iiss wwhhiicchh bbaasseedd oonn MMEEMMLL//FFFFEEPP,, bbuutt hhaass
nnootthhiinngg ttoo ddoo wwiitthh FFiinniittee EElleemmeennttss ......

 Every module or function is welcome, if you agree that it is published under
terms of the FFEP-License or the LGPL.
If the day comes when FFEP contains more NON-Finte-Element-Issues, it can be
renamed to NLOKFFEP (Numerical Library Once Known as FFEP) :-)
Beyond this, you should use doxygen to comment your code and write at least a
short section for the tutorial. The Achilles' heel of most projects is the
documentation. Feature is not everything. A person with limited time should be
able to use them!


-------------------------------------------------------------------------------