Krzysztof,
This is not a huge deal, but I believe it is worth mentioning because there is
a group of users who still want to use deal.ii on Windows.
No, I think this *is* a big deal -- thanks for being persistent and figuring
this out!
Would you mind putting a version of...
Windows 10’s
Thomas,
your code looks essentially correct, though it can be improved:
Now, for my attempt at this:
|
template(int spacedim>
void data_dot_normal (Vector data)
This copies the entire 'data' vector. You'll probably be better off making it
a 'const' reference.
{
/*{{{*/
MappingQEuleri
Dear Bruno,
I've been using the default one, Amesos_KLU, and I checked
Amesos_Superludist but trilinos doesn't recognize it.
when we installed dealii and its dependencies on the cluster, I think we
didn't uncomment the "#PACKAGES="${PACKAGES} once:superlu_dist" in
candi.cfg so it seems we need
Hamed,
On Thursday, October 27, 2016 at 5:40:04 PM UTC-4, Hamed Babaei wrote:
> First: I have parallelized a code in which I use
> TrilinosWrappers::SolverDirect
> . The problem is that with around 2 DOFs the code is run on my own
> machine and on the cluster as well but when I increase DO
I want to add that for running on Cluster I used up to 64 processors (4
nodes, each with 16 processor).
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are
Hi all,
I have two question which may be somehow related:
First: I have parallelized a code in which I use TrilinosWrappers::SolverDirect
. The problem is that with around 2 DOFs the code is run on my own
machine and on the cluster as well but when I increase DOF even to 15
it get stuc
On 10/27/2016 08:43 AM, thomas stephens wrote:
I've been thinking about this some more and there's something that I've
left out - my shape functions come from a MappingQEulerian object.
In particular, this is what the top of my assemble_system() looks like:
|
MappingQEulerian,spacedim> mappin
Dear Timo and Wolfgang,
Thank you very much for your guidance.
I should have passed the ghosted solution vector itself as the third
parameter in MappingQEulerian instead of a non-ghosted copy of it.
Best, Regards,
Hamed
On Monday, October 24, 2016 at 3:37:48 PM UTC-5, Timo Heister wrote:
>
> >
Well, here's a pretty ugly attempt -
One thing I want to point out is that my solution vector comes from a
finite element built like this: (dim=2, spacedim = 3)
FESystemfe;
fe(FE_Q(fe_degree), spacedim)
and the only DoFHandler I have lying around right now is
dof_handler.distribute_do
This is not a huge deal, but I believe it is worth mentioning because
there is a group of users who still want to use deal.ii on Windows.
Windows 10’s Anniversary Update (build 1607) brings Linux Bash Shell
based on Ubuntu. It is really easy to install and may replace (in the
future) more soph
I've been thinking about this some more and there's something that I've
left out - my shape functions come from a MappingQEulerian object.
In particular, this is what the top of my assemble_system() looks like:
MappingQEulerian,spacedim> mapping(2, dof_handler,
euler_vector);
const QGaus
Dear Praveen,
I do not use visit, but deal.II + hdf5 + paraview. Your attached file can
be opened with paraview.
But this does not mean, that we have a correct implementation within
deal.II, but I suppose it has
something to do with your visit versions or installations.
Kind regards
Uwe
On T
12 matches
Mail list logo