Re: [deal.II] Re: dealii compilation on Cray machine

Le ven. 5 avr. 2019 à 14:48, Phani Motamarri a écrit : > > No login node is intel-broadwell and compute node is intel-skylake. Problem > is that the supercomputer I am compiling on has no way to access compute node > (interactive job) directly for compiling. I am not sure if dealii allows for >

Re: [deal.II] Re: dealii compilation on Cray machine

No login node is intel-broadwell and compute node is intel-skylake. Problem is that the supercomputer I am compiling on has no way to access compute node (interactive job) directly for compiling. I am not sure if dealii allows for cross compilation. On Fri, Apr 5, 2019 at 1:44 PM Bruno Turcksin w

Re: [deal.II] Re: dealii compilation on Cray machine

Phani, Can you try the same configuration with master? Until recently there was no way to disable the simd pragma (you could only disable the intrinsics). Do the login and the compute node have the same architecture? Best, Bruno On Friday, April 5, 2019 at 1:21:45 PM UTC-4, Phani Motamarri wr

[deal.II] project_boundary_values for components

Hello, I need to apply a boundary condition (discontinuous function) to a few components of a dof_handler only. I am currently using void VectorTools::interpolate_boundary_values (const Do

Re: [deal.II] Re: dealii compilation on Cray machine

Hi Daniel, Many thanks for the reply. As you suggested, I tried a minimal configuration just using *cmake -DDEAL_II_ALLOW_AUTODETECTION=OFF -DDEAL_II_ALLOW_PLATFORM_INTROSPECTION=OFF -DCMAKE_C_COMPILER=cc -DCMAKE_CXX_COMPILER=CC -DCMAKE_Fortran_COMPILER=ftn -DMPI_C_COMPILER=cc -DMPI_CXX_COMPILER=C

Re: Re: [deal.II] Re: Applying boundary values in parll::distr:triang setting for two dof_handler Sparsematrux

Gabriel Peters Endenicher Str. 310 53121 Bonn 00491525/5478185 gabriel.pet...@koeln.de Am 05.04.19 um 15:55 schrieb Daniel Arndt > Gabriel, > > to extend on my last post. Finally, I think that your approach with the two > DoFHandler objects will give you some more problems. > What is like

[deal.II] Integrating a deal.II-specific function in a NOX-Interface for MPI-threads

I tested the integration of NOX into my program, for future nonlinear solvers. For that, I wanted to re-use the existing function for assembling the right hand side, and wrote the following code for the interface: template class ProblemInterface : public NOX::Epetra::Interface::Required,

Re: [deal.II] Poisson test code fails for a fe-degree >= 2

On 4/5/19 9:34 AM, 'Maxi Miller' via deal.II User Group wrote: > Oh, thanks! That happens if I start from an example, and don't write > everything from scratch... Since I stepped in that trap myself a couple of weeks ago and had to have Timo rescue me, I'm thinking that we ought to just change t

Re: [deal.II] Poisson test code fails for a fe-degree >= 2

Oh, thanks! That happens if I start from an example, and don't write everything from scratch... Am Donnerstag, 4. April 2019 12:25:10 UTC+2 schrieb Martin Kronbichler: > > Dear Maxi, > > The problem is the quadrature formula you use in 'assemble_system' and > 'calculate_residual'. You should use

Re: Re: [deal.II] Re: Applying boundary values in parll::distr:triang setting for two dof_handler Sparsematrux

Gabriel, to extend on my last post. Finally, I think that your approach with the two DoFHandler objects will give you some more problems. What is likely happening here is that the AffineConstraints object here is used both for rows and columns although row dofs and column dofs are unrelated. Wh

Re: Re: [deal.II] Re: Applying boundary values in parll::distr:triang setting for two dof_handler Sparsematrux

Gabriel, But I think I did a mistake somewhere in the function. Using the definiion > of the function from your pull request > I call > > *DoFTools::make_sparsity_pattern > (dof_handler_velocity,dof_handler_pressure,dsp, > constraints_vel,false);* > > and afterwards I cal