getdp issueshttps://gitlab.onelab.info/getdp/getdp/issues2017-08-05T11:55:13Zhttps://gitlab.onelab.info/getdp/getdp/issues/38Segmentation fault in GetDP 2.11.0 64-bit Windows2017-08-05T11:55:13ZChristophe GeuzaineSegmentation fault in GetDP 2.11.0 64-bit WindowsWorking with the enclosed files, the command _getdp 2D_eucard_v3.pro -pre ResolutionH -msh 2D_eucard_v3.msh_ behaves differently between the 32 and 64-bit versions of the GetDP 2.11.0 Windows executable. With the 32-bit version, the command works fine whereas with the 64-bit executable it generates a segmentation fault.
The error seems to happen while executing
```
GlobalQuantity_P = (struct GlobalQuantity*)
List_Pointer(QuantityStorage_P->FunctionSpace->GlobalQuantity,
*(int*) List_Pointer(DefineQuantity_P->IndexInFunctionSpace,0)
```
in file Kernel/Treatment_Formulation.cpp around line 669. In the 64-bit Windows version, the pointer to QuantityStorage_P->FunctionSpace is invalid (0xFFFFFFFF00000001) while it was ok in the 32-bit version. I figured the problem could be circumvented by increasing NBR_MAX_BASISFUNCTIONS in Interface/ProData.h.
[2D_eucard_v3.pro](/uploads/78e938cdc91e79d86c6b603a087ce45b/2D_eucard_v3.pro)
[2D_eucard_parameters_v3.geo](/uploads/16420bfc22441f22d67e815eafed88d2/2D_eucard_parameters_v3.geo)
[2D_eucard_v3.geo](/uploads/9f71660fedf134898d5127cc0c20e3ce/2D_eucard_v3.geo)
[2D_eucard_macros_v3.geo](/uploads/b505c587edded44d6cb5ea5e40f2192e/2D_eucard_macros_v3.geo)
[2D_eucard_display_v3.geo](/uploads/3713f5ceb202387d416462033a4a51ca/2D_eucard_display_v3.geo)
https://gitlab.onelab.info/getdp/getdp/issues/37magnetostatics simulation gives wrong results2017-08-05T11:56:16ZChristophe Geuzainemagnetostatics simulation gives wrong resultsI made a model with one magnet and an iron frame (mu_r = 9000) wrapped around it. I expect most of the B lines should go inside the iron frame, but the simulation result seems as if the iron frame does not exist. Please see attached from the geo model. Open the geo model in gmsh first, then merge (gmsh menu: File >> Merge) in magnetostatics.pro in the template folder came with gmsh. You should be able to set the model interactively. Set a constant magnetization for the magnet of 900000 in z direction. Select the right materials for air, set frame with constant mu_r = 9000, and the boundary condition on "Inf" can be either way (may leave at its default value). Then click Run.
Below is the 1magnet.geo file I used:
```
//=================start==================
// define geometry-specific parameters
mm = 1.e-3;
DefineConstant[
cub = {10*mm, Name "Parameters/2Magnet bottom size [m]"}
hite = {20*mm, Name "Parameters/2Magnet hieght [m]"}
lc1 = {TotalMemory <= 2048 ? 5*mm : 2*mm, Name "Parameters/3Mesh size on magnets [m]"}
lc2 = {TotalMemory <= 2048 ? 20*mm : 10*mm, Name "Parameters/4Mesh size at infinity [m]"}
inf = {100*mm, Name "Parameters/1Air box distance [m]"}
];
// change global Gmsh options
Mesh.Optimize = 1; // optimize quality of tetrahedra
Mesh.VolumeEdges = 0; // hide volume edges
Geometry.ExactExtrusion = 0; // to allow rotation of extruded shapes
Solver.AutoMesh = 2; // always remesh if necessary (don't reuse mesh on disk)
p1 = newp; Point(p1) = {-cub, -cub, -hite, lc1};
p2 = newp; Point(p2) = { cub, -cub, -hite, lc1};
p3 = newp; Point(p3) = { cub, cub, -hite, lc1};
p4 = newp; Point(p4) = {-cub, cub, -hite, lc1};
l1 = newl; Line(l1) = {p1,p2}; l2 = newl; Line(l2) = {p2,p3};
l3 = newl; Line(l3) = {p3,p4}; l4 = newl; Line(l4) = {p4,p1};
ll1 = newll; Line Loop(ll1) = {l1,l2,l3,l4};
s1 = news; Plane Surface(s1) = {ll1};
mag[] = Extrude {0, 0, 2*hite} { Surface{s1}; };
Physical Volume("Magnet") = {mag[1]};
//create steel frame around the magnet
p1 = newp; Point(p1) = {-2*cub, -cub, -hite, lc1};
p2 = newp; Point(p2) = { 2*cub, -cub, -hite, lc1};
p3 = newp; Point(p3) = { 2*cub, -cub, hite, lc1};
p4 = newp; Point(p4) = {-2*cub, -cub, hite, lc1};
l1 = newl; Line(l1) = {p1,p2}; l2 = newl; Line(l2) = {p2,p3};
l3 = newl; Line(l3) = {p3,p4}; l4 = newl; Line(l4) = {p4,p1};
ll1 = newll; Line Loop(ll1) = {l1,l2,l3,l4};
hite2 = hite + cub;
p1 = newp; Point(p1) = {-4*cub, -cub, -hite2, lc1};
p2 = newp; Point(p2) = { 4*cub, -cub, -hite2, lc1};
p3 = newp; Point(p3) = { 4*cub, -cub, hite2, lc1};
p4 = newp; Point(p4) = {-4*cub, -cub, hite2, lc1};
l1 = newl; Line(l1) = {p1,p2}; l2 = newl; Line(l2) = {p2,p3};
l3 = newl; Line(l3) = {p3,p4}; l4 = newl; Line(l4) = {p4,p1};
ll2 = newll; Line Loop(ll2) = {l1,l2,l3,l4};
s1 = news; Plane Surface(s1) = {ll2, ll1};
frame[] = Extrude {0, 2*cub, 0} { Surface{s1}; };
Physical Volume("Frame") = {frame[1]};
// create air box around magnets
BoundingBox; // recompute model bounding box
cx = (General.MinX + General.MaxX) / 2;
cy = (General.MinY + General.MaxY) / 2;
cz = (General.MinZ + General.MaxZ) / 2;
lx = 2*inf + General.MaxX - General.MinX;
ly = 2*inf + General.MaxY - General.MinZ;
lz = 2*inf + General.MaxZ - General.MinZ;
p1 = newp; Point (p1) = {cx-lx/2, cy-ly/2, cz-lz/2, lc2};
p2 = newp; Point (p2) = {cx+lx/2, cy-ly/2, cz-lz/2, lc2};
l1 = newl; Line(l1) = {p1, p2};
e1[] = Extrude {0, ly, 0} { Line{l1}; };
air[] = Extrude {0, 0, lz} { Surface{e1[1]}; };
slair = newsl; Surface Loop(slair) = Boundary{Volume{air[1]}; };
slmag = newsl; Surface Loop(slmag) = Boundary{Volume{mag[1]}; };
vair = newv; Volume(vair) = {slair, slmag};
Physical Volume("Air") = vair; // air
Physical Surface("Inf") = {e1[1], air[0], air[2], air[3], air[4], air[5]};
Delete { Volume{air[1]}; }
//=================end==================
```
[1magnet.geo](/uploads/7f08801b5b3492eb6d959a7606e7d989/1magnet.geo)https://gitlab.onelab.info/getdp/getdp/issues/36Higher order mesh and higher order basis functions not possible together2017-08-05T11:57:32ZChristophe GeuzaineHigher order mesh and higher order basis functions not possible togetherI attached an example where a second order mesh is used in a second order magnetodynamic problem (2D vector potential (0,0,Az), or more precisely the equivalent electric field formulation).
The Basisfunctions BF_PerpendicularEdge_2E seems not to be supported:
```
P r o c e s s i n g . . .
Info : Generate[Sys_Mag]
Error : Unknown type of Element in BF_GradNode_2E
```
Is this a defect or not yet supported? I would really like to use higher order meshes with higher order basis functions.https://gitlab.onelab.info/getdp/getdp/issues/30OnGrid Interpolation with Timestepping results in erronous output for the fir...2017-03-27T09:20:47ZChristophe GeuzaineOnGrid Interpolation with Timestepping results in erronous output for the first tilmestepIf I use OnGrid interpolation with TimeStepping in PostOperation, the first timestep that is outputted has some small errors. I've modified the Simple_RLC example to demonstrate this.
I output timesteps 90:101 and 91:101 of the vector current. When subtracting two equal time steps the difference can be seen for any subtraction that includes the first time step. Subtractions of later time steps results in zero as expected. See the attached screenshot.https://gitlab.onelab.info/getdp/getdp/issues/27time-dependent functions with time stepping schemes other than implicit Euler2017-03-27T09:20:45ZChristophe Geuzainetime-dependent functions with time stepping schemes other than implicit EulerGetDP automatically handles time-dependent constraints when they are provided using the TimeFunction mechanism in an Assign-type Constraint.
However, GetDP cannot automatically transform general time-dependent source terms in weak formulations. Such source terms will be correctly treated only for implicit Euler, as the expression in the Galerkin term is evaluated at the current time step.
For other schemes, the source term should be written explicitly, by splitting it in two (theta f_n+1 + (1-theta) f_n), making use of the AtAnteriorTimeStep[] for the second part, and specifying NeverDt in the Galerkin term.https://gitlab.onelab.info/getdp/getdp/issues/18Add function that gives size of geometric bounding box2017-03-27T09:20:40ZChristophe GeuzaineAdd function that gives size of geometric bounding boxWe should add a function that returns the values of the geom bbox stored in
GeoData_P->Xmin, etc.
This would be useful for determining regularization constantshttps://gitlab.onelab.info/getdp/getdp/issues/10generalize localterm2017-08-05T12:01:19ZChristophe Geuzainegeneralize localtermgeneralize localterm (equation part should call Cal_vBFxDof)https://gitlab.onelab.info/getdp/getdp/issues/9Should recompute Current.x,y,z in Cal_vBFxDof?2017-03-27T09:20:54ZChristophe GeuzaineShould recompute Current.x,y,z in Cal_vBFxDof?subject says it all...https://gitlab.onelab.info/getdp/getdp/issues/6SetFrequency2017-03-27T09:20:53ZChristophe GeuzaineSetFrequencyverify if the post-pro uses the correct frequency for each system if
the frequency was changed by hand using SetFrequency in the
resolution, in between two GenerateSystemhttps://gitlab.onelab.info/getdp/getdp/issues/4access Time & TimeImag in post-processing2017-03-27T09:20:53ZChristophe Geuzaineaccess Time & TimeImag in post-processingSubject says it all (mostly useful for eigenvalues Re/Im)https://gitlab.onelab.info/getdp/getdp/issues/3complex conjugation problem with sparskit2017-03-27T09:20:53ZChristophe Geuzainecomplex conjugation problem with sparskitWith sparsekit and 3D modelling in getdp I found an
error. If one includes terms like
Galerkin { [ Einc[], {E} ]; In port; Integration I1;
Jacobian Jac;}
Where Einc is purely imaginary then sparsekit complex conjugates it.
It is only a problem in 3D. In 2D it does not exist. The problem
also disappers with petsc.