Deal Luca and Jean-Paul,
Thanks for the help. I've already been able to run the code. Although it
runs with default values, this surely is related with the last lines
written by Luca in his message.
jomivalen@Nalia ~/ifem/ans-ifem-master $ ./ifem parameters.prm
Parameter
On 12/17/2016 03:24 PM, seyedali88 via deal.II User Group wrote:
It sounds like the right direction. What happens when you try?
I tried the following:
std::vector > invJ = fe_values.get_inverse_jacobians
();
This compiles fine.
I don't understand the question. Since this is the retu
>
> It sounds like the right direction. What happens when you try?
I tried the following:
std::vector > invJ =
fe_values.get_inverse_jacobians ();
This compiles fine.
I don't understand the question. Since this is the return type, why can't
> you
> just store these objects as given?
N
Am Samstag, 17. Dezember 2016 23:22:06 UTC+1 schrieb
seyed...@googlemail.com:
>
> It sounds like the right direction. What happens when you try?
>
>
> I tried the following:
>
> std::vector > invJ =
> fe_values.get_inverse_jacobians ();
>
> This compiles fine.
>
> I don't understand the quest
>
> It sounds like the right direction. What happens when you try?
I tried the following:
std::vector > invJ =
fe_values.get_inverse_jacobians ();
This compiles fine.
I don't understand the question. Since this is the return type, why can't
> you
> just store these objects as given?
N
Dear Joaquin,
As a supplement to Luca's message, with every release of deal.II there is
the possibility that we introduce some incompatibilities that break
existing code. This is what must have happened here - I assume that you've
upgraded from version 8.2.1 or earlier to something newer, and t
On Sat, Dec 17, 2016 at 8:41 PM, Denis Davydov wrote:
> That looks like something is wrong in deal.II configuration tests.
> Correct me if I am wrong, but 8.4.2 installs ok for you with Spack but the
> current @develop fails,
> so the changes must have been introduced after 8.4.2 release.
>
> Yes
That looks like something is wrong in deal.II configuration tests.
Correct me if I am wrong, but 8.4.2 installs ok for you with Spack but the
current @develop fails,
so the changes must have been introduced after 8.4.2 release.
@all: any ideas on how to debug it further or what could be the prob
After 45 min, cmake is still at
-- Performing Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG
so I killed it. Let me know if you want me to wait longer with hope of
getting some error message.
Thanks
praveen
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
I am now again trying
spack install dealii@develop
It is here
*==>* gsl is already installed in
/home/spack/opt/spack/linux-opensuse20161212-x86_64/gcc-6/gsl-2.2.1-rqhjfsomxyrou5mdrtedrtbamhh5msic
*==>* openblas is already installed in
/home/spack/opt/spack/linux-opensuse20161212-x86_64/gcc-6/o
> On 17 Dec 2016, at 12:59, Praveen C wrote:
>
> I used instructions on wiki like this
>
> DEAL_II_VIEW=/home/soft
>
> cmake \
> -DCMAKE_FIND_FRAMEWORK=LAST \
> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE \
> -DCMAKE_INSTALL_RPATH=${DEAL_II_VIEW} \
> -DCMAKE_BUILD_TYPE=DebugRelease \
> -DDE
On Sat, Dec 17, 2016 at 5:26 PM, Denis Davydov wrote:
> Alternative, is to add the view to your path, i.e.
>
> PATH=${DEAL_II_VIEW}/bin:${PATH}
>
> then
>
> -DCMAKE_C_COMPILER="mpicc"
>
> would also be ok.
>
I used instructions on wiki like this
DEAL_II_VIEW=/home/soft
cmake \
-DCMAKE_FIND_
Alternative, is to add the view to your path, i.e.
PATH=${DEAL_II_VIEW}/bin:${PATH}
then
-DCMAKE_C_COMPILER="mpicc"
would also be ok.
On Saturday, December 17, 2016 at 12:52:44 PM UTC+1, Denis Davydov wrote:
>
> To clarify with FileSystem views, you would need to do
>
> ${DEAL_II_VIEW}/bin/m
To clarify with FileSystem views, you would need to do
${DEAL_II_VIEW}/bin/mpicc
to make sure MPI is picked up the view, and not the one from the system.
On Friday, December 16, 2016 at 3:22:45 PM UTC+1, Praveen C wrote:
>
> Hello Jean-Paul, Denis
>
> Thanks for the tips. I had huge problems
Dear Joaquin,
as I wrote to you on one of my previous emails, the repository
https://github.com/luca-heltai/ans-ifem
contains a branch that compiles correctly, without those warnings, on the
development version of deal.II.
There are some more warnings due to the deprecation of the ‘sadd’ func
Dear Anup,
one option you have is to use a Triangulation.
I would still use two scalar extractors:
const FEValuesExtractors::Scalar u_x
const FEValuesExtractors::Scalar u_y
Tensor<2,dim+1> gradient;
gradient[0] = fe_values_ref[u_x].gradient(k, q_point)
gradient[1] = fe_values_ref[u_y].gradien
16 matches
Mail list logo
