From Guillaume.DILASSER at cea.fr Thu Jan 5 10:14:39 2017 From: Guillaume.DILASSER at cea.fr (DILASSER Guillaume) Date: Thu, 5 Jan 2017 09:14:39 +0000 Subject: [Getdp] Erroneous interaction between constraints Message-ID: Dear GetDP community, I am facing a problem with the implementation of constraints in a magnetodynamical model : I basically have two constraints to enforce and they interact badly in a way that is almost unpredictable, causing erroneous results. First, I enclose with this mail a schematics to explain the problem. To simplify, I am considering one fourth of the cross-section (the top-right part) of a dipole in 2D. I have a conducting domain that is carrying a known current I in the Z-direction (note that the current density itself is not set). There is a symmetry with the X-axis, the lower-right corner should also have a conductor carrying I, and with the Y-axis, the top-left and bottom-left corner having each a conductor with a -I current. To achieve this, I am using the H-Phi formulation and I use two separate constraints : ? One on the current flowing through the upper-right conductor. This is done by generating ? cut in the air with the Cohomology module, then I create a DoF on it and constraining it to be my total current. ? Second is a Phi = cst condition on the X-axis to generate the mirror symmetry. However, Cohomology generates its edge chain randomly and when it hits the X-axis, then the two constraints interact badly and mess the solution up. If I understand well, in this case, Phi should be equal to a constant on the elements of the X-axis on one side of the cohomology cut and another constant on the other side, with the difference between the constants being the Jump in Phi over the cut. Am I correct with this ? I know that an option to circumvent the problem would be to model half of the windings instead of one fourth like I am doing now. By modeling the complete right side for example, I would get rid of the boundary condition on the X-axis and thus of the problem. However, this also mean doubling the size of my model and I would like to avoid it if possible. Thus, I would like to know if someone knows how I could change the implementation of my constraints to get the correct effect. Your help would be greatly appreciated. Sincerely yours, Guillaume DILASSER Doctorant SACM / LEAS CEA - Centre de Saclay - B?t.123 - PC 319c 91191 Gif sur Yvette Cedex - France - guillaume.dilasser at cea.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OneFourthDipoleSchematic.jpg Type: image/jpeg Size: 39401 bytes Desc: OneFourthDipoleSchematic.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WrongFieldExample.jpg Type: image/jpeg Size: 431531 bytes Desc: WrongFieldExample.jpg URL: From Geoffrey.LOSSAUNEN at umons.ac.be Fri Jan 20 15:04:11 2017 From: Geoffrey.LOSSAUNEN at umons.ac.be (Geoffrey LOSSA UNEN) Date: Fri, 20 Jan 2017 14:04:11 +0000 Subject: [Getdp] Using H-Phi form. Case of an inductor (axisymmetric 2D model) Message-ID: Dear Getdp members, I'm wondering if it's possible to couple global quantities (I flowing through the conductors or V between the terminals) of the 2D axisymmetric model of an inductor (see the attached figure) with the local quantites in case of magnetodynamics H-Phi formulation (by using the cohomology basis functions). I'd like to set the voltage across the terminals and then to compute weakly the current density in the conductors. Could you give me some advices on how to do ? Thanks in advance, Geoffrey L. UMons Phd student General Physics Unit -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_Inductor.png Type: image/png Size: 11321 bytes Desc: 2D_Inductor.png URL: From funkybob at gmail.com Mon Jan 30 16:41:01 2017 From: funkybob at gmail.com (Jasper) Date: Mon, 30 Jan 2017 16:41:01 +0100 Subject: [Getdp] 3D Magnetostatics with Scalar Potential and Current Source Message-ID: Hi, I'm trying to setup a magnetostatic calculation with a scalar potential. I would like have an inductor as the source of the field. The basis for the formulation is slides 32-35 of the following presentation: http://getdp.info/doc/slides_getdp.pdf For the source field computation I adapted a Onelab example since the formulation in the slides appears incomplete. This is probably where there is some mistake as the resulting field does not make sense to me. Can anybody help me figure out what's wrong? Should I use another approach for including the source field? The vector potential version seems OK, but I would like to have it with a scalar potential. I've attached the files. Any help would be much appreciated! Best regards, Jasper -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IndSta3DLinScalar.zip Type: application/zip Size: 4133 bytes Desc: not available URL: From Geoffrey.LOSSAUNEN at umons.ac.be Wed Feb 1 10:02:10 2017 From: Geoffrey.LOSSAUNEN at umons.ac.be (Geoffrey LOSSA UNEN) Date: Wed, 1 Feb 2017 09:02:10 +0000 Subject: [Getdp] Error Getdp: Redefinition of Function nu_1 Message-ID: Dear Getdp members, I'm testing the Onelab Getdp 2D model of Inductor/core system template in order to compute the eddy current and Joule losses generated in the conducting core. But I meet an error while compolling the template : (BH.pro, line 4) Redefinition of Function nu_1a. Does anyone know what is missing or wrong ? Thank you in advance for the help, Geoffrey L. UMons Phd. Student General Physics Unit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruth.sabariego at kuleuven.be Thu Feb 2 08:43:05 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Thu, 2 Feb 2017 07:43:05 +0000 Subject: [Getdp] Error Getdp: Redefinition of Function nu_1 In-Reply-To: References: Message-ID: <46623EF6-2D0B-4685-9191-B770855A336F@kuleuven.be> Dear Geoffrey, That?s the kind of message you get when you define a function twice (same name in one of your pro-files). I?ve just checked the template and there is no redefinition there. BTW, that function is related to the bh-curve and therefore should not use in the frequency domain computation that I guess you are using for getting the eddy currents. HTH, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 1 Feb 2017, at 10:02, Geoffrey LOSSA UNEN > wrote: Dear Getdp members, I?m testing the Onelab Getdp 2D model of Inductor/core system template in order to compute the eddy current and Joule losses generated in the conducting core. But I meet an error while compolling the template : (BH.pro, line 4) Redefinition of Function nu_1a. Does anyone know what is missing or wrong ? Thank you in advance for the help, Geoffrey L. UMons Phd. Student General Physics Unit _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftrillaudp at pumas.ii.unam.mx Sat Feb 11 02:25:06 2017 From: ftrillaudp at pumas.ii.unam.mx (Frederic Trillaud Pighi) Date: Fri, 10 Feb 2017 19:25:06 -0600 Subject: [Getdp] Issue with cohomology solver Message-ID: <1486776306.5048.4.camel@pumas.ii.unam.mx> Dear all, I do not know if I am doing wrong here. I have an axisymmetric model of superconducting tapes in parallel carrying the same impressed current. In the case of triangular mesh, all the tapes carry the current in the same direction leading to the expected total current integrated over all the tapes. However, when I use quadrangles (exact same code), the first tape does not have the same direction of current as the remaining tape. It seems that there is an issue with the association of the current with the cut. I may think that it is some kind of a bug resulting from the choice of quadrangle meshing. I have joined the code based and resulting results. Best, Frederic -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangle2TapeMesh.png Type: image/png Size: 9164 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles2Tapes.png Type: image/png Size: 82858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles2TapesCurrent.png Type: image/png Size: 51296 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles3TapeCurrent.png Type: image/png Size: 179327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles3TapesMesh.png Type: image/png Size: 10128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles4Tapes.png Type: image/png Size: 61274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: quadrangles4TapesCurrent.png Type: image/png Size: 123597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: triangle2Tapes.png Type: image/png Size: 59756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: triangle2TapesMesh.png Type: image/png Size: 22273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: triangles2TapesCurrent.png Type: image/png Size: 133155 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hts_bench_3.geo Type: text/x-csrc Size: 6034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hts_bench_3.par Type: text/x-csrc Size: 2191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hts_bench_3.pro Type: text/x-csrc Size: 15859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: integration.par Type: text/x-csrc Size: 1302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jacobian.par Type: text/x-csrc Size: 790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.sh Type: application/x-shellscript Size: 2411 bytes Desc: not available URL: From Guillaume.DILASSER at cea.fr Mon Feb 13 08:40:19 2017 From: Guillaume.DILASSER at cea.fr (DILASSER Guillaume) Date: Mon, 13 Feb 2017 07:40:19 +0000 Subject: [Getdp] Issue with cohomology solver In-Reply-To: <1486776306.5048.4.camel@pumas.ii.unam.mx> References: <1486776306.5048.4.camel@pumas.ii.unam.mx> Message-ID: Dear Frederic, Your issue is caused by inconsistent orientation of cohomology cuts. If you mesh and generate cohomology cuts for your model within the Gmsh GUI, you will see that 3 of your cuts are oriented in one direction and the one corresponding to the first turn is in the opposite direction. Therefore the current flows in the opposite direction in the first turn. A quick fix is to set up your current constraint in the pro file on a per turn basis (put +I on each turn with the correct orientation and -I on the other) but this is not practical when the number of turns grows. Another solution is to post-process the msh file and reverse the orientation of each line element within the cuts that have bad orientation (this is presently what I do). There may be a way to handle the issue directly in Gmsh but unfortunately I was not able to find it. Sincerely Yours, Guillaume DILASSER Doctorant SACM / LEAS CEA - Centre de Saclay - B?t.123 - PC 319c 91191 Gif sur Yvette Cedex - France - guillaume.dilasser at cea.fr -----Message d'origine----- De : getdp [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] De la part de Frederic Trillaud Pighi Envoy? : samedi 11 f?vrier 2017 02:25 ? : getdp at geuz.org Cc : Cesar Sim?n Lopez Monsalvo Objet : [Getdp] Issue with cohomology solver Dear all, I do not know if I am doing wrong here. I have an axisymmetric model of superconducting tapes in parallel carrying the same impressed current. In the case of triangular mesh, all the tapes carry the current in the same direction leading to the expected total current integrated over all the tapes. However, when I use quadrangles (exact same code), the first tape does not have the same direction of current as the remaining tape. It seems that there is an issue with the association of the current with the cut. I may think that it is some kind of a bug resulting from the choice of quadrangle meshing. I have joined the code based and resulting results. Best, Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftrillaudp at pumas.ii.unam.mx Mon Feb 13 15:51:56 2017 From: ftrillaudp at pumas.ii.unam.mx (Frederic Trillaud Pighi) Date: Mon, 13 Feb 2017 08:51:56 -0600 Subject: [Getdp] Issue with cohomology solver In-Reply-To: References: <1486776306.5048.4.camel@pumas.ii.unam.mx> Message-ID: <67EF9462-36C9-49AA-B0DB-66829BEF6047@pumas.ii.unam.mx> Dear Guillaume, Thanks for the quick answer, it is then an actual bug. IN my understanding, the current orientation should provide the orientation of the cut. I have already implemented the proposed solution, it is not so ideal but it leads to a temporary fix. Best, Frederic > On Feb 13, 2017, at 01:40, DILASSER Guillaume wrote: > > Dear Frederic, > > Your issue is caused by inconsistent orientation of cohomology cuts. If you mesh and generate cohomology cuts for your model within the Gmsh GUI, you will see that 3 of your cuts are oriented in one direction and the one corresponding to the first turn is in the opposite direction. Therefore the current flows in the opposite direction in the first turn. A quick fix is to set up your current constraint in the pro file on a per turn basis (put +I on each turn with the correct orientation and -I on the other) but this is not practical when the number of turns grows. Another solution is to post-process the msh file and reverse the orientation of each line element within the cuts that have bad orientation (this is presently what I do). There may be a way to handle the issue directly in Gmsh but unfortunately I was not able to find it. > > Sincerely Yours, > > Guillaume DILASSER > Doctorant SACM / LEAS > CEA - Centre de Saclay - B?t.123 - PC 319c > 91191 Gif sur Yvette Cedex - France - > > guillaume.dilasser at cea.fr > > > -----Message d'origine----- > De : getdp [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] De la part de Frederic Trillaud Pighi > Envoy? : samedi 11 f?vrier 2017 02:25 > ? : getdp at geuz.org > Cc : Cesar Sim?n Lopez Monsalvo > Objet : [Getdp] Issue with cohomology solver > > Dear all, > > I do not know if I am doing wrong here. I have an axisymmetric model of superconducting tapes in parallel carrying the same impressed current. > > In the case of triangular mesh, all the tapes carry the current in the same direction leading to the expected total current integrated over all the tapes. However, when I use quadrangles (exact same code), the first tape does not have the same direction of current as the remaining tape. It seems that there is an issue with the association of the current with the cut. I may think that it is some kind of a bug resulting from the choice of quadrangle meshing. > > I have joined the code based and resulting results. > > Best, > > Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylan at phbs.pku.edu.cn Mon Feb 13 12:05:18 2017 From: ylan at phbs.pku.edu.cn (=?UTF-8?B?6JOd6aKW5p2w?=) Date: Mon, 13 Feb 2017 19:05:18 +0800 (GMT+08:00) Subject: [Getdp] bug: magnetostatics simulation gives wrong results Message-ID: <6cc954b3.92b0.15a3725f254.Coremail.ylan@phbs.pku.edu.cn> Hi team, I made a model with one magnet and an iron frame 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.Attached is the 1magnet.geo file I used. Regards, Yingjie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1magnet.geo Type: application/octet-stream Size: 3078 bytes Desc: not available URL: From Guillaume.DILASSER at cea.fr Tue Feb 14 11:26:30 2017 From: Guillaume.DILASSER at cea.fr (DILASSER Guillaume) Date: Tue, 14 Feb 2017 10:26:30 +0000 Subject: [Getdp] GetDP crash as size of problem increases Message-ID: Dear GetDP developpers, I encountered a sudden crash of GetDP while I was trying to run the enclosed model (with getdp 2D_eucard_v3.pro -solve ResolutionH -msh 2D_eucard_v3.msh). The same model with fewer conductors and a slightly smaller air bounding box worked fine, change for example NbTurns=20 / NbTurnsBlock[] = { 10, 10 } in the 2D_eucard_prameters_v3.geo file to verify it. In the current state, GetDP crashes during the pre-processing step while generating some ExtendedGroup. According to MS visual studio debugger it is a segmentation fault (Unhandled exception at 0x004e5d56 in getdp.exe: 0xC0000005: Access violation reading location 0xffffffff00000021). Any lead on what might be happening ? Is it related to the increasing size of the model ? Additional info, I use GetDP 2.11 on Windows 8.1 but the problem happened also with previous versions of GetDP (namely 2.10 and 2.8). Guillaume DILASSER Doctorant SACM / LEAS CEA - Centre de Saclay - B?t.123 - PC 319c 91191 Gif sur Yvette Cedex - France - guillaume.dilasser at cea.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_eucard_display_v3.geo Type: application/octet-stream Size: 1540 bytes Desc: 2D_eucard_display_v3.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_eucard_macros_v3.geo Type: application/octet-stream Size: 5099 bytes Desc: 2D_eucard_macros_v3.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_eucard_parameters_v3.geo Type: application/octet-stream Size: 4822 bytes Desc: 2D_eucard_parameters_v3.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_eucard_v3.geo Type: application/octet-stream Size: 6349 bytes Desc: 2D_eucard_v3.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2D_eucard_v3.pro Type: application/octet-stream Size: 17743 bytes Desc: 2D_eucard_v3.pro URL: From ylan at phbs.pku.edu.cn Tue Feb 14 11:57:23 2017 From: ylan at phbs.pku.edu.cn (=?UTF-8?B?6JOd6aKW5p2w?=) Date: Tue, 14 Feb 2017 18:57:23 +0800 (GMT+08:00) Subject: [Getdp] bug: magnetostatics simulation gives wrong results In-Reply-To: <6cc954b3.92b0.15a3725f254.Coremail.ylan@phbs.pku.edu.cn> References: <6cc954b3.92b0.15a3725f254.Coremail.ylan@phbs.pku.edu.cn> Message-ID: <4541ff00.a2e9.15a3c450f66.Coremail.ylan@phbs.pku.edu.cn> Hi onelab team, The problem is mine: I did not exclude the body of the frame from the air volume. Sorry for the premature report, I am new to gmsh and learned really hard past few days. After having corrected my mistake, and increased mesh size (if mesh size is too small, getdp will report an external library error, probably due to too many elements), I finally got my simulation result! I'd like to thank you for this great tool and toy! Attached are the new geo file and the screen shot of the result with the settings. Feel free to use it as an example for others to see how nice and powerful getdp is! This is a serious tool for 3d magnetostatic simulation! I haven't got any where with other free tools so far. Best, Yingjie -----Original Messages----- From:"???" Sent Time:2017-02-13 19:05:18 (Monday) To: getdp at onelab.info Cc: Subject: bug: magnetostatics simulation gives wrong results Hi team, I made a model with one magnet and an iron frame 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.Attached is the 1magnet.geo file I used. Regards, Yingjie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1magnet.geo Type: application/octet-stream Size: 4184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1magnet.jpg Type: image/jpeg Size: 360941 bytes Desc: not available URL: From ruth.sabariego at kuleuven.be Thu Feb 16 09:20:19 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Thu, 16 Feb 2017 08:20:19 +0000 Subject: [Getdp] GetDP crash as size of problem increases In-Reply-To: References: Message-ID: <67DD9681-D1F8-4223-BC21-7B909993784D@kuleuven.be> Dear Guillaume, I think you just run out of memory due to the non-dynamic memory stack which is used in the recursive function Cal_WholeQuantity (Kernel/Cal_Quantity.cpp). It is done like that for performance reasons, and changing it needs a complete rewriting of part of the code. A work-around could be increasing the value of MAX_STACK_SIZE (default value is 40 in Interface/ProData.h). HTH, Best regards, Ruth Sabariego ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info > On 14 Feb 2017, at 11:26, DILASSER Guillaume wrote: > > Dear GetDP developpers, > > I encountered a sudden crash of GetDP while I was trying to run the enclosed model (with getdp 2D_eucard_v3.pro ?solve ResolutionH ?msh 2D_eucard_v3.msh). The same model with fewer conductors and a slightly smaller air bounding box worked fine, change for example NbTurns=20 / NbTurnsBlock[] = { 10, 10 } in the 2D_eucard_prameters_v3.geo file to verify it. In the current state, GetDP crashes during the pre-processing step while generating some ExtendedGroup. According to MS visual studio debugger it is a segmentation fault (Unhandled exception at 0x004e5d56 in getdp.exe: 0xC0000005: Access violation reading location 0xffffffff00000021). Any lead on what might be happening ? Is it related to the increasing size of the model ? Additional info, I use GetDP 2.11 on Windows 8.1 but the problem happened also with previous versions of GetDP (namely 2.10 and 2.8). > > Guillaume DILASSER > Doctorant SACM / LEAS > CEA - Centre de Saclay - B?t.123 - PC 319c > 91191 Gif sur Yvette Cedex - France - > > guillaume.dilasser at cea.fr > > <2D_eucard_display_v3.geo><2D_eucard_macros_v3.geo><2D_eucard_parameters_v3.geo><2D_eucard_v3.geo><2D_eucard_v3.pro>_______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp From Geoffrey.LOSSAUNEN at umons.ac.be Fri Feb 17 12:20:46 2017 From: Geoffrey.LOSSAUNEN at umons.ac.be (Geoffrey LOSSA UNEN) Date: Fri, 17 Feb 2017 11:20:46 +0000 Subject: [Getdp] TR: Using H-Phi form. Case of an inductor (axisymmetric 2D model) References: Message-ID: Dear Getdp member, Is it possible to use cohomology functions for a 2D model of an inductor with massive conductors in case of H-Phi formulatiion? If yes, what could be the circuit coupling constraints with the global quantities ? The H-Phi formulation here, is just an another way to compute some outputs parameters from the numerical model and compare them with those obtained previously by using a-v formulation. Thanks in advance for the help, Geoffrey L. UMons Phd student General Physics Unit De : Geoffrey LOSSA UNEN Envoy? : mardi 24 janvier 2017 10:54 ? : 'Ruth Vazquez Sabariego' Objet : RE: [Getdp] Using H-Phi form. Case of an inductor (axisymmetric 2D model) Yes, I?ve already tried that and it runs well. Now I want to frame some outputs values from the numerical model by using A-v and H-Phi formulations in magnetodynamics. Best regards, Geoffrey De : Ruth Vazquez Sabariego [mailto:ruth.sabariego at kuleuven.be] Envoy? : mardi 24 janvier 2017 10:12 ? : Geoffrey LOSSA UNEN > Objet : Re: [Getdp] Using H-Phi form. Case of an inductor (axisymmetric 2D model) Dear Geoffrey, Just with the figure you attach, I do not see why you need the cohomology functions in this axisymmetric model. Defining a circuit would be enough for imposing V and getting the currents in the conductors. Have you tried that? Best regards, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 20 Jan 2017, at 15:04, Geoffrey LOSSA UNEN > wrote: Dear Getdp members, I?m wondering if it?s possible to couple global quantities (I flowing through the conductors or V between the terminals) of the 2D axisymmetric model of an inductor (see the attached figure) with the local quantites in case of magnetodynamics H-Phi formulation (by using the cohomology basis functions). I?d like to set the voltage across the terminals and then to compute weakly the current density in the conductors. Could you give me some advices on how to do ? Thanks in advance, Geoffrey L. UMons Phd student General Physics Unit <2D_Inductor.png>_______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From Guillaume.DILASSER at cea.fr Mon Feb 27 16:51:05 2017 From: Guillaume.DILASSER at cea.fr (DILASSER Guillaume) Date: Mon, 27 Feb 2017 15:51:05 +0000 Subject: [Getdp] Wrong edge number in 'BF_Edge' Message-ID: Dear GetDP developpers, I am facing a problem when dealing with a model that contains a lot of basis functions. Using the official release of GetDP 2.11 for 32-bit Windows, I am able to perform the pre-processing stage. However, when I try to start the actual computation (with the -cal option) with the same executable, I get the error "Number of basis function (89) exceeds NBR_MAX_BASISFUNCTIONS : please recompile after changing Interface/ProData.h". As suggested, I recompiled GetDP with NBR_MAX_BASISFUNCTIONS = 150 but now I get the error "Wrong Edge number in 'Bf_Edge'". Indeed, I have looked and at one point I am calling the BF_Edge function with NumEdge equal to some large value that changes from execution to the next (for ex. 796683696). To me, it looks like uninitialized variable but I did not manage to solve it. Do you have any clue on what is going on. Sincerely Yours, Guillaume DILASSER Doctorant SACM / LEAS CEA - Centre de Saclay - B?t.123 - PC 319c 91191 Gif sur Yvette Cedex - France - guillaume.dilasser at cea.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From shkliaryk.yu.n at gmail.com Sat Mar 11 22:06:19 2017 From: shkliaryk.yu.n at gmail.com (Yury Shkliaryk) Date: Sun, 12 Mar 2017 00:06:19 +0300 Subject: [Getdp] Infinite shell transformations Message-ID: Dear All, I try to solve some problems for Laplace equation with open boundary, so I need to set zero boundary condition on infinity. I tried to use VolAxiRectShell to resolve this issue but I see unexpected potential distribution near inner boundaries of rectangular shells. I attached my scripts and plot of iso-lines of solution. In this example Laplace equation for conductive circular 2D disk was solved using axial symmetry. Behavior of iso-lines in non-transformed area near inner boundaries of shells is strange. Iso-lines seem to be "attracted" to the border. Could you please check what's wrong? In general, it's not clear how to use *shell transformations and what do some arguments stand for. I didn't find any details in getDP documentation. I found only one related article: "Finite element modeling of unbounded problems using transformations: A rigorous, powerful and easy solution". Looks like the described transformations are implemented in getDP but I can't be sure that they are implemented in exactly same way (for example, I'm not sure that center-X, center-Y, center-Z are coordinates of transformation center described in the article). Also I want to solve multidomain problem for Laplace equation but I need to know formulas of these transformations to adjust geometry of surfaces which separate domains in areas of shells. Could somebody please update documentation to make information about shell transformations more clear? Thanks a lot! Best regards, Yury -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DiskLaplaceAxi.zip Type: application/zip Size: 353061 bytes Desc: not available URL: From riccardo.scorretti at ec-lyon.fr Thu Mar 16 15:48:08 2017 From: riccardo.scorretti at ec-lyon.fr (Riccardo Scorretti) Date: Thu, 16 Mar 2017 15:48:08 +0100 Subject: [Getdp] Problems when compiling GetDP on Linux Message-ID: <059a75e8-d936-caab-b698-0c17a924a56f@ec-lyon.fr> An HTML attachment was scrubbed... URL: From marsic at temf.tu-darmstadt.de Thu Mar 16 17:17:06 2017 From: marsic at temf.tu-darmstadt.de (Marsic, Nicolas) Date: Thu, 16 Mar 2017 16:17:06 +0000 Subject: [Getdp] Problems when compiling GetDP on Linux In-Reply-To: <059a75e8-d936-caab-b698-0c17a924a56f@ec-lyon.fr> References: <059a75e8-d936-caab-b698-0c17a924a56f@ec-lyon.fr> Message-ID: <3321f449-a200-723b-9cef-85596f550212@temf.tu-darmstadt.de> Hi Riccardo, It seems that PETSc is using MPIUNI. I guess that the PETSc you use is the serial one. Actually, MPIUNI allows you to use PETSc in an environment without MPI. If this is indeed the case, you have to recompile it with the MPI support. Hope this helps, Nicolas. On 16/03/17 15:48, Riccardo Scorretti wrote: > Hi. > I have troubles for compiling GetDP on my Linux system. The problem > seems to be related to MPI libraries. I followed the instructions at > http://onelab.info/wiki/GetDP#GetDP_models but the compilation fails > when linking GetDP due to some missing symbols (see below for details). > At present time, the only method I could find to compile GetDP is to run > ccmake .. from /getdp/bin and disable PETSC, which is not the best solution. > Do you have any ideas about how fixing this problem ? > > Riccardo Scorretti > > > > [100%] Linking CXX executable getdp > CMakeFiles/getdp.dir/Common/Message.cpp.o : Dans la fonction ? Message::Initialize(int, char**) ? : > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:106 : r?f?rence ind?finie vers ? Petsc_MPI_Init ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:107 : r?f?rence ind?finie vers ? Petsc_MPI_Comm_rank ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:108 : r?f?rence ind?finie vers ? Petsc_MPI_Comm_size ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:109 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Common/Message.cpp.o : Dans la fonction ? Message::Cpu(int, bool, bool, bool, bool, bool, char const*, ...) ? : > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:479 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:479 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:480 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:480 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:481 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:481 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Common/Message.cpp.o : Dans la fonction ? Message::Barrier() ? : > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:1243 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Common/Message.cpp.o : Dans la fonction ? Message::Finalize() ? : > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:143 : r?f?rence ind?finie vers ? Petsc_MPI_Initialized ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:144 : r?f?rence ind?finie vers ? Petsc_MPI_Finalized ? > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:146 : r?f?rence ind?finie vers ? Petsc_MPI_Finalize ? > CMakeFiles/getdp.dir/Common/Message.cpp.o : Dans la fonction ? Message::Exit(int) ? : > /home/scorretti/Data/Sources/getdp/Common/Message.cpp:163 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > CMakeFiles/getdp.dir/Kernel/SolvingOperations.cpp.o : Dans la fonction ? Treatment_Operation(Resolution*, List_T*, DofData*, GeoData*, Resolution*, DofData*) ? : > /home/scorretti/Data/Sources/getdp/Kernel/SolvingOperations.cpp:3174 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Kernel/Operation_IterativeLinearSolver.cpp.o : Dans la fonction ? PViewBCast(ILSField, ILSField, std::set, std::allocator > const&) [clone .constprop.279] ? : > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:439 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:446 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:515 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:480 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:480 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:507 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:507 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:515 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Kernel/Operation_IterativeLinearSolver.cpp.o : Dans la fonction ? InitData(ILSField*, ILSField*, Operation*, std::vector >, std::allocator > > >, std::allocator >, std::allocator > > > > >*) [clone .isra.267] [clone .constprop.274] ? : > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:165 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:165 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:196 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:196 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:199 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:199 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:217 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:217 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:221 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:221 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:268 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:268 : r?f?rence ind?finie vers ? MPIUNI_Memcpy ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:403 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:371 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:371 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:373 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:373 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:394 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:394 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:396 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:396 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > CMakeFiles/getdp.dir/Kernel/Operation_IterativeLinearSolver.cpp.o : Dans la fonction ? Operation_IterativeLinearSolver(Resolution*, Operation*, DofData*, GeoData*) ? : > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:1018 : r?f?rence ind?finie vers ? MPIUNI_TMP ? > CMakeFiles/getdp.dir/Kernel/Operation_IterativeLinearSolver.cpp.o : Dans la fonction ? BuildIterationMatrix ? : > /home/scorretti/Data/Sources/getdp/Kernel/Operation_IterativeLinearSolver.cpp:767 : r?f?rence ind?finie vers ? Petsc_MPI_Comm_size ? > CMakeFiles/getdp.dir/Kernel/EigenSolve_SLEPC.cpp.o : Dans la fonction ? _try(int) [clone .part.10] ? : > /home/scorretti/Data/Sources/getdp/Kernel/EigenSolve_SLEPC.cpp:54 : r?f?rence ind?finie vers ? Petsc_MPI_Abort ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? OMPI_C_MPI_NULL_DELETE_FN ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_lor ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_in_place__ ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Win_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_STATUS_IGNORE ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_comm_null ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_ARGV_NULL ? > //usr/lib/x86_64-linux-gnu/libfftw3_mpi.so.3 : r?f?rence ind?finie vers ? ompi_mpi_unsigned ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_datatype_match_size ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Errhandler_c2f ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_errors_are_fatal ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? MPI_Comm_f2c ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_char ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_param_check ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_long_int ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_short ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_double ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_finalized ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_attr_create_keyval ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_land ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_argv_null__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_2integer ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_cxx_ldblcplex ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_replace ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_win_null ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_character ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_fortran_multiple_argvs_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_UNWEIGHTED ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_cxx_dblcplex ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_bor ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_2dblprec ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_errhandler_create ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_registered_datareps ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Group_f2c ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_short_int ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_bottom__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_unsigned_long_long ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_errcode_intern_lastused ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_minloc ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_datatype_null ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_file_null ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_group_null ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_comm_self ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_bxor ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_CONVERSION_FN_NULL ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_float_int ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_lxor ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_long_double ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_prod ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_2int ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_lb ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_unsigned_char ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_IN_PLACE ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Message_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_errhandler_null ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_unsigned_long ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_packed ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_errcodes_ignore__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_signed_char ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_op_max ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_maxloc ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_fortran_string_f2c ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_op_min ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_set_fortran_mpi2 ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? OMPI_C_MPI_NULL_COPY_FN ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_create_keyval_aint ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_byte ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_info_null ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_comm_world ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_set_fortran_mpi1 ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Info_f2c ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_float ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_ERRCODES_IGNORE ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_request_null ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_cplex ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_errors_return ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_unsigned_short ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? MPI_Comm_c2f ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_status_empty ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Win_c2f ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_create_keyval_fint ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_BOTTOM ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_statuses_ignore__ ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_int64_t ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_double_int ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_fortran_argv_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Errhandler_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_conversion_fn_null_ ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_unweighted__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_wchar ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_ARGVS_NULL ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_op_set_cxx_callback ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_int ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_get_fortran_mpi2 ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_initialized ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Info_c2f ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_errors_throw_exceptions ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_long_long_int ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_integer ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_attr_get_fortran_mpi1 ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_dblprec ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_conversion_fn_null__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_2real ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_errhandler_invoke ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_long ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? MPI_Type_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Op_f2c ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Request_f2c ? > //usr/lib/libptscotch-5.1.so : r?f?rence ind?finie vers ? ompi_mpi_ub ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_WEIGHTS_EMPTY ? > /usr/lib/x86_64-linux-gnu/libpetsc.so : r?f?rence ind?finie vers ? ompi_mpi_op_band ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_op_null ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_errcodes_intern ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Group_c2f ? > /usr/lib/x86_64-linux-gnu/libslepc.so : r?f?rence ind?finie vers ? ompi_mpi_op_sum ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_conversion_fn_null ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_FORTRAN_STATUSES_IGNORE ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Op_c2f ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_status_ignore__ ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_fortran_string_c2f ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_logical ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_cxx_bool ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_cxx_cplex ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_real ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? ompi_mpi_errors_are_fatal_comm_handler ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_weights_empty__ ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? mpi_fortran_argvs_null__ ? > //usr/lib/libmpi_cxx.so.1 : r?f?rence ind?finie vers ? ompi_mpi_group_empty ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Type_c2f ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Request_c2f ? > //usr/lib/libmpi_mpifh.so.12 : r?f?rence ind?finie vers ? MPI_Message_c2f ? > collect2: error: ld returned 1 exit status > CMakeFiles/getdp.dir/build.make:2990 : la recette pour la cible ? getdp ? a ?chou?e > make[2]: *** [getdp] Erreur 1 > CMakeFiles/Makefile2:1123 : la recette pour la cible ? CMakeFiles/getdp.dir/all ? a ?chou?e > make[1]: *** [CMakeFiles/getdp.dir/all] Erreur 2 > Makefile:160 : la recette pour la cible ? all ? a ?chou?e > make: *** [all] Erreur 2 > > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > From oleg.ryabkov.87 at gmail.com Fri Mar 17 14:27:23 2017 From: oleg.ryabkov.87 at gmail.com (=?UTF-8?B?0J7Qu9C10LMg0KDRj9Cx0LrQvtCy?=) Date: Fri, 17 Mar 2017 16:27:23 +0300 Subject: [Getdp] getdp + gmsh High order pos files Message-ID: Dear gmsh/getdp users and developers. Is there any way to output results of getdp calculaltions directly into high order gmsh pos format. I mean we have operations like Print[u, OnElementsOf Omega, File "u_Dirichlet.pos", Depth 2]; in which we can specify elements depth subdivision, which is nice, but it would be even nicer, if one could output high order getdp solutions directly to high order pos format. I didn't find any clue in getdp documentation, that's why i'm asking here. PS here i mean 'parsed pos', but in fact, any high order gmsh (or any other software) post processing format is great. -- Best regards, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgeuzaine at ulg.ac.be Sat Mar 18 09:50:16 2017 From: cgeuzaine at ulg.ac.be (Christophe Geuzaine) Date: Sat, 18 Mar 2017 09:50:16 +0100 Subject: [Getdp] [Gmsh] getdp + gmsh High order pos files In-Reply-To: References: Message-ID: <20A837E1-088F-4B14-AFAA-E363206A1D98@ulg.ac.be> > On 17 Mar 2017, at 14:27, ???? ?????? wrote: > > Dear gmsh/getdp users and developers. > Is there any way to output results of getdp calculaltions directly into high order gmsh pos format. I mean we have operations like > > Print[u, OnElementsOf Omega, File "u_Dirichlet.pos", Depth 2]; > > in which we can specify elements depth subdivision, which is nice, but it would be even nicer, if one could output high order getdp solutions directly to high order pos format. I didn't find any clue in getdp documentation, that's why i'm asking here. > > PS here i mean 'parsed pos', but in fact, any high order gmsh (or any other software) post processing format is great. > It's currently not supported by GetDP - it's on our TODO list... Christophe > -- > Best regards, Oleg > _______________________________________________ > gmsh mailing list > gmsh at onelab.info > http://onelab.info/mailman/listinfo/gmsh -- Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine Free software: http://gmsh.info | http://getdp.info | http://onelab.info From cgeuzaine at ulg.ac.be Mon Mar 27 21:01:05 2017 From: cgeuzaine at ulg.ac.be (Christophe Geuzaine) Date: Mon, 27 Mar 2017 21:01:05 +0200 Subject: [Getdp] Switch to Git Message-ID: Dear all, GetDP development has moved to Git: http://gitlab.onelab.info/getdp/getdp. (The old subversion repository has become read-only.) Christophe -- Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine Free software: http://gmsh.info | http://getdp.info | http://onelab.info From ferranfabro at gmail.com Tue Mar 28 12:23:04 2017 From: ferranfabro at gmail.com (Ferran Fabro) Date: Tue, 28 Mar 2017 12:23:04 +0200 Subject: [Getdp] Current distribution and magnetic field Message-ID: Hi, We are new working with getdp and gmsh. We want to solve the following problem (see attached geometry) We want to induce a current in volume 1 and get the current distribution in volumes 2 and 3 and get the magnetic field in volume 4. We have some doubts about: - Current injection - Boundary Conditions Thank you very much Ferran Fabr? Tapia - https://about.me/ferranfabro Lightning Research Group: https://lrg.upc.edu/en ferranfabro at gmail.com ferran.fabro at upc.edu No imprimeixis aquest correu a no ser que sigui estrictament necessari -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geometry.png Type: image/png Size: 13824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: example1.geo Type: application/octet-stream Size: 3709 bytes Desc: not available URL: From pabloxjara at gmail.com Wed Apr 12 08:52:35 2017 From: pabloxjara at gmail.com (Pablo Xavier Jara Palacios) Date: Tue, 11 Apr 2017 23:52:35 -0700 Subject: [Getdp] Question about force on magnets Message-ID: Hi, I was reviewing the .pro file in example of magnet which is posted in onelab's page, but I do not understand how the force is calculated in this problem. There is a dummy term in the formulation that I do not know what it is. Please help me with this doubt. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruth.sabariego at kuleuven.be Wed Apr 12 16:43:20 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Wed, 12 Apr 2017 14:43:20 +0000 Subject: [Getdp] Question about force on magnets In-Reply-To: References: Message-ID: <73DDB4D4-8D7E-42CF-8E1D-2AA0E13B9B7D@kuleuven.be> Dear Pablo Xavier, The force is calculated by means of the Maxwell Stress Tensor with the local normal computed with the help of an auxiliary basis function. The dummy term added in the formulation is then only used in the post-processing stage for the force computation. The unknowns linked to this basis function un are indeed fully fixed and linked to a layer of elements touching the magnet. We impose 1 at the boundary of the magnet and the rest of the values are 0, as the function varies linearly per element, the gradient gives the normal modulus the size of the element. HTH, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 12 Apr 2017, at 08:52, Pablo Xavier Jara Palacios > wrote: Hi, I was reviewing the .pro file in example of magnet which is posted in onelab's page, but I do not understand how the force is calculated in this problem. There is a dummy term in the formulation that I do not know what it is. Please help me with this doubt. Regards, _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruth.sabariego at kuleuven.be Thu Apr 13 09:56:55 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Thu, 13 Apr 2017 07:56:55 +0000 Subject: [Getdp] Question about force on magnets In-Reply-To: References: <73DDB4D4-8D7E-42CF-8E1D-2AA0E13B9B7D@kuleuven.be> Message-ID: <5BBFFD03-691C-44EF-BF97-7CDCF04ECADF@kuleuven.be> On 13 Apr 2017, at 09:38, Pablo Xavier Jara Palacios > wrote: Thanks Ruth, I really appreciate your help. Do you mean that un is used for the purpose of compute the normal direction of the force on each magnet?. Not on each magnet but on each element that touches the boundary of the magnet. On the other hand, in the weak formulation this part "Galerkin { [ 0 * Dof{un~{i}} , {un~{i}} ]" is a separetely equation or is part of the same equation of the weak formulation either scalar o vector potential? You can see it as a dummy equation, as it has no influence on the system you are actually solving. It is an additional equation with the only objective of generating the degrees of freedom (Dofs), they are set to zero unless indicated otherwise via a constraint. The thing is that I do not undestand how un is computed if there is a 0 that is multipliying inside the integranl, so I would suppose that everything is canceled out in the integral. As I said, it is not computed. All the coefficients associated with that basis function are set to zero except the ones fixed via the constraint => the boundary is set to one. In this point is where I do not know how un is calculated at the end. Please maybe could you recommend me any book or paper where I could find a similar example? I do not think there is an example of this as is. The 0 multiplying an equation, it is just a GetDP trick for getting the local normal. The papers you can have a look at are those dealing with the Maxwell Stress Tensor, also called Arkkio method in the electrical-machine modelling community. Have a look at: A. Arkkio, Analysis of induction motors based on the numerical solution of the magnetic field and circuit equations , Acta Polytechnica Scandinavica, 1987, p. 56 Z. Ren, A. Razek, Local force computation in deformable bodies using edge elements , IEEE Trans. Magnetics, 28(2):1212?1215, 1992. F. Henrotte, G. Delie?ge, K. Hameyer, The eggshell approach for the computations of electromagnetic forces in 2D and 3D , COMPEL, 23(4), 996?1005, 2004. Regards, Ruth regards, 2017-04-12 7:43 GMT-07:00 Ruth Vazquez Sabariego >: Dear Pablo Xavier, The force is calculated by means of the Maxwell Stress Tensor with the local normal computed with the help of an auxiliary basis function. The dummy term added in the formulation is then only used in the post-processing stage for the force computation. The unknowns linked to this basis function un are indeed fully fixed and linked to a layer of elements touching the magnet. We impose 1 at the boundary of the magnet and the rest of the values are 0, as the function varies linearly per element, the gradient gives the normal modulus the size of the element. HTH, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 12 Apr 2017, at 08:52, Pablo Xavier Jara Palacios wrote: Hi, I was reviewing the .pro file in example of magnet which is posted in onelab's page, but I do not understand how the force is calculated in this problem. There is a dummy term in the formulation that I do not know what it is. Please help me with this doubt. Regards, _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From integer2 at inbox.lv Fri Apr 21 12:43:15 2017 From: integer2 at inbox.lv (Tomas) Date: Fri, 21 Apr 2017 13:43:15 +0300 Subject: [Getdp] GetDP .res file Message-ID: <1492771395.58f9e243ecc85@mail.inbox.lv> An HTML attachment was scrubbed... URL: From ftrillaudp at gmail.com Tue May 9 18:56:37 2017 From: ftrillaudp at gmail.com (Frederic Trillaud) Date: Tue, 9 May 2017 11:56:37 -0500 Subject: [Getdp] eddy current problem in 3D - not giving proper results Message-ID: Dear all, I am stuck with the following problem. I have a conductive cube (W_c) under a background fluctuating magnetic field created by an external coil (W_m), both surrounded by air (W_a). I have used the inductor model of GetDP to create my own *.pro (cube.pro). The mesh was created in the salome platform and converted using gmsh to *.msh format (see main.sh file). I am using the gauged A-V formulation with a current j_a in the background electromagnet (no symmetry, all 3D). The gauge is applied using the Tree-Cotree condensation. I cannot get a proper results on the magnetic field (see attached image). The results do not make sense and I don't understand what I missed. If someone can take a look at it to see if there is a simple answer. I use the latest version of onelab. Thanks in advance, best, Frederic -------------- next part -------------- A non-text attachment was scrubbed... Name: shared.zip Type: application/zip Size: 221917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.sh Type: application/x-shellscript Size: 2094 bytes Desc: not available URL: From ftrillaudp at gmail.com Tue May 9 18:59:10 2017 From: ftrillaudp at gmail.com (Frederic Trillaud) Date: Tue, 9 May 2017 11:59:10 -0500 Subject: [Getdp] image - eddy current problem in 3D - not giving proper results In-Reply-To: References: Message-ID: <449bd95f-22c0-76fd-75d2-37ac66a3bf6d@gmail.com> MIssing the results in previous email. sorry Dear all, I am stuck with the following problem. I have a conductive cube (W_c) under a background fluctuating magnetic field created by an external coil (W_m), both surrounded by air (W_a). I have used the inductor model of GetDP to create my own *.pro (cube.pro). The mesh was created in the salome platform and converted using gmsh to *.msh format (see main.sh file). I am using the gauged A-V formulation with a current j_a in the background electromagnet (no symmetry, all 3D). The gauge is applied using the Tree-Cotree condensation. I cannot get a proper results on the magnetic field (see attached image). The results do not make sense and I don't understand what I missed. If someone can take a look at it to see if there is a simple answer. I use the latest version of onelab. Thanks in advance, best, Frederic -------------- next part -------------- A non-text attachment was scrubbed... Name: shared.zip Type: application/zip Size: 221917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.sh Type: application/x-shellscript Size: 2094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vectorB.png Type: image/png Size: 43946 bytes Desc: not available URL: From diomarti at ulb.ac.be Mon May 15 18:49:02 2017 From: diomarti at ulb.ac.be (Diogo Pinto) Date: Mon, 15 May 2017 18:49:02 +0200 Subject: [Getdp] Issue building and installing GetDP from Source Message-ID: Hi all, I wanted to build GetDP from source (on a mac but same error on Linux) but I encounter an error when running the make command. I installed PETSc which automatically downloaded BLAS/LAPACK? with the command : ??????? ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich --download-fblaslapack When running cmake on GetDP, the different compilers and required packages (PETSc, BLAS/LAPACK) are found on the system. However when running make, there is an error popping up stating that there is a header file (petscconf.h) missing. Did someone encounter this issue before, if yes what has to be done to solve this ? Thanks in advance, Diogo Pinto ------------------------------------------------------- Phd Student BEAMS Department Universit? Libre de Bruxelles Avenue Franklin Roosevelt 50 1050 Bruxelles (Belgium) Email : diomarti at ulb.ac.be -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruth.sabariego at kuleuven.be Mon May 15 20:58:38 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Mon, 15 May 2017 18:58:38 +0000 Subject: [Getdp] Issue building and installing GetDP from Source In-Reply-To: References: Message-ID: Hi Diogo, Are your environmental variables properly defined? Have a look at http://onelab.info/wiki/GetDP Once PETSc is installed, PETSC_DIR and PETSC_ARCH have to be available for compiling GetDP with PETSc. Best regards, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 15 May 2017, at 18:49, Diogo Pinto > wrote: Hi all, I wanted to build GetDP from source (on a mac but same error on Linux) but I encounter an error when running the make command. I installed PETSc which automatically downloaded BLAS/LAPACK with the command : ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich --download-fblaslapack When running cmake on GetDP, the different compilers and required packages (PETSc, BLAS/LAPACK) are found on the system. However when running make, there is an error popping up stating that there is a header file (petscconf.h) missing. Did someone encounter this issue before, if yes what has to be done to solve this ? Thanks in advance, Diogo Pinto ------------------------------------------------------- Phd Student BEAMS Department Universit? Libre de Bruxelles Avenue Franklin Roosevelt 50 1050 Bruxelles (Belgium) Email : diomarti at ulb.ac.be _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From sesc at gmx.de Mon May 15 21:10:07 2017 From: sesc at gmx.de (=?utf-8?Q?Sebastian_Sch=C3=B6ps?=) Date: Mon, 15 May 2017 21:10:07 +0200 Subject: [Getdp] getdp Digest, Vol 170, Issue 3 In-Reply-To: References: Message-ID: <4B3953FE-3A8C-46DB-8BD9-6F3AF2876115@gmx.de> > Date: Mon, 15 May 2017 18:49:02 +0200 > From: Diogo Pinto > To: > Subject: [Getdp] Issue building and installing GetDP from Source > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I wanted to build GetDP from source (on a mac but same error on Linux) but I encounter an error when running the make command. A quick and small advertisement: Mac users can also use homebrew (https://brew.sh) to install gmsh and getdp from source, e.g. brew tap science brew install getdp Bye Sebastian From diomarti at ulb.ac.be Thu May 18 17:45:56 2017 From: diomarti at ulb.ac.be (Diogo Pinto) Date: Thu, 18 May 2017 17:45:56 +0200 Subject: [Getdp] Issue building and installing GetDP from Source In-Reply-To: References: Message-ID: <7C13EED7-9FE2-404E-9373-E1B49CBAB3AF@ulb.ac.be> Hello Ms. Sabariego, I set up my environment variables as specified on the website (http://onelab.info/wiki/GetDP) but now there appears to be an error regarding an undeclared identifier (Py_DecodeLocale). A screenshot of the error message is in attachment. Thank you for the help, Diogo From: Ruth Vazquez Sabariego Date: Monday, 15 May 2017 at 20:58 To: Diogo Pinto Cc: "getdp at onelab.info" Subject: Re: [Getdp] Issue building and installing GetDP from Source Hi Diogo, Are your environmental variables properly defined? Have a look at http://onelab.info/wiki/GetDP Once PETSc is installed, PETSC_DIR and PETSC_ARCH have to be available for compiling GetDP with PETSc. Best regards, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 15 May 2017, at 18:49, Diogo Pinto wrote: Hi all, I wanted to build GetDP from source (on a mac but same error on Linux) but I encounter an error when running the make command. I installed PETSc which automatically downloaded BLAS/LAPACK with the command : ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich --download-fblaslapack When running cmake on GetDP, the different compilers and required packages (PETSc, BLAS/LAPACK) are found on the system. However when running make, there is an error popping up stating that there is a header file (petscconf.h) missing. Did someone encounter this issue before, if yes what has to be done to solve this ? Thanks in advance, Diogo Pinto ------------------------------------------------------- Phd Student BEAMS Department Universit? Libre de Bruxelles Avenue Franklin Roosevelt 50 1050 Bruxelles (Belgium) Email : diomarti at ulb.ac.be _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Error_Compiling_GetDP.png Type: image/png Size: 33845 bytes Desc: not available URL: From Guillaume.DILASSER at cea.fr Fri Jun 9 08:54:29 2017 From: Guillaume.DILASSER at cea.fr (DILASSER Guillaume) Date: Fri, 9 Jun 2017 06:54:29 +0000 Subject: [Getdp] Hodge dual operator ? Message-ID: Hi everyone, I have been looking through GetDP's documentation and mailing list history but did not find any clue on the existence of an explicit Hodge star operator... Is it implemented ? If not what would be the best way to compute it ? Just as an example, I am looking for a way to write a formulation term for *d(*u) with u a 1-form. Sincerely Yours, Guillaume DILASSER Doctorant SACM / LEAS CEA - Centre de Saclay - B?t.123 - PC 319c 91191 Gif sur Yvette Cedex - France - guillaume.dilasser at cea.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From vskych at gmail.com Thu Jun 15 16:32:05 2017 From: vskych at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQpdC+0YDQvtGI0LXQsg==?=) Date: Thu, 15 Jun 2017 17:32:05 +0300 Subject: [Getdp] Hysteresis Message-ID: Dear Patrick Dular and Christophe Geuzaine! The file "F_Hysteresis.cpp" (from GetDP source code) contains several hysteresis models. Are there any examples of their use (for example, the case described in "Christophe Gu?rin, K?vin Jacques, Ruth V. Sabariego, Patrick Dular, Christophe Geuzaine, Johan Gyselinck / Using a Jiles-Atherton vector hysteresis model for isotropic magnetic materials with the finite element method, Newton-Raphson method, and relaxation procedure"; or the example used in "Riccardo Scorretti, Ruth Sabariego, Fabian Sixdeniers, Benjamin Ducharne, Marie-Ange Raulet / Integration of a new hysteresis model in the Finite Elements method" (Ducharne's hysteresis model?)) or another guide information? Theoretically, is it possible to simulate magnetic hysteresis in a problem with a moving object when it is solved in getdp? Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco_antolovic at yahoo.it Sat Jul 15 15:40:40 2017 From: marco_antolovic at yahoo.it (Marco Antolovic) Date: Sat, 15 Jul 2017 13:40:40 +0000 (UTC) Subject: [Getdp] first post References: <1357386513.1251074.1500126040293.ref@mail.yahoo.com> Message-ID: <1357386513.1251074.1500126040293@mail.yahoo.com> Hi everybody! This is my first post on the GetDP list, I'm an electrical engineer that is starting to have a look at the world of numerical methods for PDE. I'm interested in vibro-acoustic and electromagnetics problems but at the moment I'm more focused on the latter. Specifically, 3D models for electric motors and PCB tracks inductance extraction. I came across GetDP while using Gmsh (thanks a lot for this nice peace of software!!). I like the idea of having single environment where I can do everything so I decided to give it a go. I had a look at the 2D motor example and I was wandering if the periodic boundaries can be used in the 3D case as well.Also, always in 3D motor models, when it is required to solve for B through the entire electrical cycle, do you have to create a new geometry/mesh for each rotor position or there is some other way to do that? Any help on the subject is much appreciated. Marco PS: By the way, I'd like to report a bug on a demo file on the OneLab page?GetDP - ONELAB | | | | | | | | | | | GetDP - ONELAB | | | | If you download the ONELAB bundle file (in the getting started section) for desktop (I've tried windows and Mac versions) and try to run the demo on the inductor (3D case) you will find that it doesn't work, this is due to wrong extrude commands starting at line 76 (inductor3D.geo), see an example below: vol[] = Extrude Surface {surf_ECore[0], {0,0,-Lz/2}};; once these are corrected the geometry is built nicely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From franz.g.nowak at gmail.com Tue Jul 18 18:13:52 2017 From: franz.g.nowak at gmail.com (Franz Nowak) Date: Tue, 18 Jul 2017 18:13:52 +0200 Subject: [Getdp] Scalar Field line integral, projection onto surface Message-ID: Dear Christophe, dear Patrick First of all, huge compliment on your software! I am a student of computer science trying to learn FEM over the summer and quickly came across gmsh, getdp, and onelab, which I find very intriguing. Could you help me with the following problem: I am trying to model a charged parallel plate capacitor in 3d, calculate the potential field and then project the field along an axis onto a plane: Each point on the plane should have the sum (integral) of the potential field along the line of projection as a value. My solution would be to use For-loops to construct hundreds or thousands of lines through my mesh in Gmsh and then calculate the line integrals in GetDP, inside the Electrostatics template, for each single line something like this: { Name polarisation; Value { Integral { [ {v} ] ; In IntLine[i]; Jacobian Sur; Integration Int; } } However this takes too long to compute and generally seems very ugly... surely there is a more elegant way? My geometry is the following: // Gmsh project created on Fri Jul 14 14:02:04 2017 SetFactory("OpenCASCADE"); //+ Box(1) = {-5, -5, -5, 10, 10, 10}; //+ Box(2) = {-0.5, -0.5, -1, 1, 0.1, 2}; //+ Box(3) = {-0.5, 0.4, -1, 1, 0.1, 2}; //+ Surface Loop(4) = {3, 2, 5, 1, 6, 4}; //+ Surface Loop(5) = {10, 11, 7, 9, 8, 12}; //+ Surface Loop(6) = {16, 17, 13, 15, 14, 18}; //+ Volume(4) = {4, 5, 6}; //+ Physical Volume("vacuum") = {4}; //+ Recursive Delete { Volume{1}; } //+ Recursive Delete { Volume{3}; } //+ Recursive Delete { Volume{2}; } //+ Physical Surface("pos") = {7,8,9,10,11,12}; //+ Physical Surface("neg") = {13,14,15,16,17,18}; /* For k In {-5:5:0.1} For n In {-5:5:0.1} p=newp; Point(p)={k,n,-5,1}; p=newp; Point(p)={k,n,5,1}; EndFor EndFor ? ( Lines, Physical Lines etc.) */ Best wishes, Franz -------------- next part -------------- An HTML attachment was scrubbed... URL: From brahim.azzabi-zouraq at etu.univ-nantes.fr Thu Jul 27 13:49:54 2017 From: brahim.azzabi-zouraq at etu.univ-nantes.fr (AZZABI ZOURAQ) Date: Thu, 27 Jul 2017 13:49:54 +0200 Subject: [Getdp] extracting data on mesh nodes that belongs to a line Message-ID: <88c876b7-8c91-4dde-330e-11bb5581c843@etu.univ-nantes.fr> Hi , i'm a PHD student and i am working on an NDT technic based on electrothermal phenomenas. Currently ,I'm using getdp to simulate a nucelar defect case. I wanted to extract power density value over a line of my conducting domain. I used the following command : x0 = (odef/2+(0.10712e-3/2)) ; y0 =pdef ; y1=-hp+pdef; z0 =0; Print [ roj2, OnLine{{x0,y0,z0}{x0,y1,z0}}{nbDivs}, File "Line_roj2phex.pos"] ; Print [ roj2, OnLine{{x0,y0,z0}{x0,y1,z0}}{nbDivs}, File "Line_roj2phex", Format Gnuplot] ; Using this , i have interpolated values aver the chosen line. My goal is to have only values over the mesh nodes that belongs to the line (without interpolation values). Is there a way to do this using gmsh ? Thanks, Brahim From michael.asam at infineon.com Fri Jul 28 09:38:01 2017 From: michael.asam at infineon.com (michael.asam at infineon.com) Date: Fri, 28 Jul 2017 07:38:01 +0000 Subject: [Getdp] extracting data on mesh nodes that belongs to a line In-Reply-To: <88c876b7-8c91-4dde-330e-11bb5581c843@etu.univ-nantes.fr> References: <88c876b7-8c91-4dde-330e-11bb5581c843@etu.univ-nantes.fr> Message-ID: <40ddc4be10b14057943cec2794faa44a@MUCSE605.infineon.com> Hi Brahim, the output format NodeTable in GetDP's PostOperation should do what you want. The line has to be a real line in your geometry with a physical group for referring it in the PostOperation. Here comes a small example showing the usage and creation of tables. For your case, just look the PostOperation "H_Nodetable". I hope, it is of some help. Cheers, Michael -----Original Message----- From: getdp [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] On Behalf Of AZZABI ZOURAQ Sent: Thursday, July 27, 2017 1:50 PM To: getdp at onelab.info Subject: [Getdp] extracting data on mesh nodes that belongs to a line Hi , i'm a PHD student and i am working on an NDT technic based on electrothermal phenomenas. Currently ,I'm using getdp to simulate a nucelar defect case. I wanted to extract power density value over a line of my conducting domain. I used the following command : x0 = (odef/2+(0.10712e-3/2)) ; y0 =pdef ; y1=-hp+pdef; z0 =0; Print [ roj2, OnLine{{x0,y0,z0}{x0,y1,z0}}{nbDivs}, File "Line_roj2phex.pos"] ; Print [ roj2, OnLine{{x0,y0,z0}{x0,y1,z0}}{nbDivs}, File "Line_roj2phex", Format Gnuplot] ; Using this , i have interpolated values aver the chosen line. My goal is to have only values over the mesh nodes that belongs to the line (without interpolation values). Is there a way to do this using gmsh ? Thanks, Brahim _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- A non-text attachment was scrubbed... Name: Table.geo Type: application/octet-stream Size: 432 bytes Desc: Table.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Table.pro Type: application/octet-stream Size: 6875 bytes Desc: Table.pro URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Table_1D.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Table_2D.txt URL: From quemener at lpccaen.in2p3.fr Wed Aug 9 09:45:47 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Wed, 9 Aug 2017 09:45:47 +0200 (CEST) Subject: [Getdp] GetDP MPI versus single CPU Message-ID: <1761319893.9108.1502264747286.JavaMail.zimbra@lpccaen.in2p3.fr> Hi, I have compiled GetDP with MPI option under Linux Ubuntu 16.04 on a machine w/ 6x2 CPUs and 32 MB of RAM. When running the magnet.pro file given in the GetDP demos folder, I was expecting to get faster results with MPI than w/o and was quite surprise by the comparison as shown by the following outputs : 1) MPI run: *********** mpirun -np 12 /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi -pos MagSta_phi Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 12 nodes] Info : Started (Wed Aug 9 09:20:20 2017, Wall = 0.277839s, CPU = 0.884s [0.04s,0.116s], Mem = 287.254Mb [23.4609Mb,27.6289Mb]) Info : Increasing process stack size (8192 kB < 16 MB) Info : Loading problem definition 'magnet.pro' Info : Loading problem definition 'magnet_data.pro' Info : Loading problem definition '../templates/MaterialDatabase.pro' Info : Loading problem definition '../templates/MaterialMacros.pro' Info : Loading problem definition '../templates/Magnetostatics.pro' Info : Selected Resolution 'MagSta_phi' Info : Loading Geometric data 'magnet.msh' Info : System 'A' : Real P r e - P r o c e s s i n g . . . Info : Treatment Formulation 'MagSta_phi' Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) Info : [rank 8] System 1/1: 1658225 Dofs Info : [rank 7] System 1/1: 1658225 Dofs Info : [rank 3] System 1/1: 1658225 Dofs Info : [rank 4] System 1/1: 1658225 Dofs Info : [rank 1] System 1/1: 1658225 Dofs Info : [rank 2] System 1/1: 1658225 Dofs Info : [rank 10] System 1/1: 1658225 Dofs Info : [rank 6] System 1/1: 1658225 Dofs Info : [rank 5] System 1/1: 1658225 Dofs Info : [rank 11] System 1/1: 1658225 Dofs Info : [rank 0] System 1/1: 1658225 Dofs Info : [rank 9] System 1/1: 1658225 Dofs Info : (Wall = 30.3178s, CPU = 181.936s [14.804s,16.964s], Mem = 8228.93Mb [685.133Mb,689.43Mb]) E n d P r e - P r o c e s s i n g P r o c e s s i n g . . . Info : CreateDir[../templates/res/] Info : Generate[A] Info : Solve[A] Info : N: 1658225 - preonly lu mumps Info : SaveSolution[A] Info : (Wall = 87.9995s, CPU = 489.904s [38.456s,48.752s], Mem = 14249.9Mb [1109.46Mb,1297.96Mb]) E n d P r o c e s s i n g P o s t - P r o c e s s i n g . . . Info : NameOfSystem not set in PostProcessing: selected 'A' Info : Selected PostProcessing 'MagSta_phi' Info : Selected Mesh 'magnet.msh' Info : PostOperation 1/4 > 'res/MagSta_phi_hc.pos' Info : PostOperation 2/4 > 'res/MagSta_phi_phi.pos' Info : PostOperation 3/4 > 'res/MagSta_phi_h.pos' Info : PostOperation 4/4 > 'res/MagSta_phi_b.pos' Info : (Wall = 377.562s, CPU = 1118.17s [80.556s,207.128s], Mem = 14254.1Mb [1109.95Mb,1297.96Mb]) E n d P o s t - P r o c e s s i n g Info : Stopped (Wed Aug 9 09:26:37 2017, Wall = 377.851s, CPU = 2012.12s [162.712s,207.26s], Mem = 14254.1Mb [1109.95Mb,1297.96Mb]) 2) Single CPU run: ****************** /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi -pos MagSta_phi Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 1 node] Info : Started (Wed Aug 9 09:27:06 2017, Wall = 0.146171s, CPU = 0.136s, Mem = 25.9609Mb) Info : Increasing process stack size (8192 kB < 16 MB) Info : Loading problem definition 'magnet.pro' Info : Loading problem definition 'magnet_data.pro' Info : Loading problem definition '../templates/MaterialDatabase.pro' Info : Loading problem definition '../templates/MaterialMacros.pro' Info : Loading problem definition '../templates/Magnetostatics.pro' Info : Selected Resolution 'MagSta_phi' Info : Loading Geometric data 'magnet.msh' Info : System 'A' : Real P r e - P r o c e s s i n g . . . Info : Treatment Formulation 'MagSta_phi' Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) Info : System 1/1: 1658225 Dofs Info : (Wall = 10.7856s, CPU = 7.42s, Mem = 688.309Mb) E n d P r e - P r o c e s s i n g P r o c e s s i n g . . . Info : CreateDir[../templates/res/] Info : Generate[A] Info : Solve[A] Info : N: 1658225 - preonly lu mumps Info : SaveSolution[A] Info : (Wall = 40.7256s, CPU = 47.028s, Mem = 4496.32Mb) E n d P r o c e s s i n g P o s t - P r o c e s s i n g . . . Info : NameOfSystem not set in PostProcessing: selected 'A' Info : Selected PostProcessing 'MagSta_phi' Info : Selected Mesh 'magnet.msh' Info : PostOperation 1/4 > 'res/MagSta_phi_hc.pos' Info : PostOperation 2/4 > 'res/MagSta_phi_phi.pos' Info : PostOperation 3/4 > 'res/MagSta_phi_h.pos' Info : PostOperation 4/4 > 'res/MagSta_phi_b.pos' Info : (Wall = 324.758s, CPU = 132.924s, Mem = 4496.32Mb) E n d P o s t - P r o c e s s i n g Info : Stopped (Wed Aug 9 09:32:31 2017, Wall = 324.946s, CPU = 133.032s, Mem = 4496.32Mb) Does any one has clues to explain such a behaviour ? Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From quemener at lpccaen.in2p3.fr Wed Aug 9 10:21:31 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Wed, 9 Aug 2017 10:21:31 +0200 (CEST) Subject: [Getdp] Permanent magnet in GetDP Message-ID: <1233082569.9591.1502266891190.JavaMail.zimbra@lpccaen.in2p3.fr> Hi, When simulating permanent NdFeB magnets in a homemade BEM program, I use a permeability of 1.05 and a remanent magnetization/field depending on the magnet grade as given for instance in the following table : Minimum Values Grade Br Hc (Hcb) Hci (Hcj) BHmax (T) (kA/m) (kA/m) (kJ/m?) N27 1.030 796 955 199 N30 1.080 796 955 223 N33 1.130 836 955 247 N35 1.170 867 955 263 N38 1.210 899 955 287 N40 1.240 923 955 302 N42 1.280 923 955 318 N45 1.320 875 955 342 N48 1.380 836 875 366 N50 1.400 796 875 382 N52 1.430 796 875 398 Looking closer to the magnet.xxx files in the GetDP demos folder, I cannot figure out how the remanent magnetization is taken into account as only Hc seems to be used in the material definition. I would think that both Hc and Br should be used. How would one distinguish between N40 and N42 grades which have the same Hc values ? How the fact that an N50 magnet has a larger remanent field than an N40 one is accounted for in GetDP when Hc(N50) is smaller than Hc(N40) and equal to Hc(N27) ? Thanks a lot for any hints, Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From quemener at lpccaen.in2p3.fr Wed Aug 9 11:55:06 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Wed, 9 Aug 2017 11:55:06 +0200 (CEST) Subject: [Getdp] Permanent magnet in GetDP In-Reply-To: <1233082569.9591.1502266891190.JavaMail.zimbra@lpccaen.in2p3.fr> References: <1233082569.9591.1502266891190.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: <473537205.10740.1502272506886.JavaMail.zimbra@lpccaen.in2p3.fr> Hi, Following my previous message, I digged more into the .pro files of GetDP demos magnet.xxx and it seems that one could perhaps use both Hc and ?_r to distinguish between NdFeB magnets grades. In GetDP demos, the permanent magnets material could be defined as in MaterialDatabase.pro w/ the following lines : // NdFeB magnet N45 Materials() += Str[ "NdFeB_Grade_N45" ]; NdFeB_mur = 1.172; // Br = 1370 mT, Hcb = 930000 A/m and ?_r = Br / Hcb / ?_o NdFeB_sigma = 2e5; NdFeB_hc = 930000; where ?_r and Hcb values have been taken from the ttypical table below. Could anyone confirm or infirm this approach ? Remanence coercivity coercivity product Br Hcb Hcj B H max ? = Br / Hcb ?_r= ? / ?o mT kA/m kA/m kJ/m3 T/A/m min typ min typ min min typ ?C N-35 1170 1120 870 920 955 263 279 80 1.217391E-06 0.969 N-38 1220 1260 870 920 955 279 303 80 1.369565E-06 1.090 N-40 1260 1300 870 920 955 303 318 80 1.413043E-06 1.124 N-42 1300 1330 870 920 955 318 334 80 1.445652E-06 1.150 N-45 1330 1370 900 930 955 334 358 80 1.473118E-06 1.172 N-48 1370 1410 900 930 875 358 382 80 1.516129E-06 1.206 N-50 1410 1440 830 850 875 382 398 80 1.694118E-06 1.348 N-52 1430 1480 820 840 875 398 422 80 1.761905E-06 1.402 N-33M 1140 1170 830 859 1114 239 263 100 1.362049E-06 1.084 N-35M 1170 1220 870 891 1114 263 279 100 1.369248E-06 1.090 N-38M 1220 1260 900 915 1114 279 303 100 1.377049E-06 1.096 N-40M 1260 1300 930 915 1114 303 318 100 1.420765E-06 1.131 N-42M 1300 1330 950 915 1114 318 334 100 1.453552E-06 1.157 N-45M 1330 1370 980 915 1114 334 358 100 1.497268E-06 1.191 N-48M 1370 1410 1010 980 1114 358 382 90 1.438776E-06 1.145 N-50M 1410 1440 1030 980 1114 382 398 90 1.469388E-06 1.169 N-30H 1080 1140 810 810 1353 223 239 120 1.407407E-06 1.120 N-33H 1140 1170 830 830 1353 239 263 120 1.409639E-06 1.122 N-35H 1170 1220 870 870 1353 263 279 120 1.402299E-06 1.116 N-38H 1220 1260 900 900 1353 279 303 120 1.400000E-06 1.114 N-40H 1260 1300 930 930 1353 303 318 120 1.397849E-06 1.112 N-42H 1300 1330 950 950 1353 318 334 120 1.400000E-06 1.114 N-44H 1330 1360 970 970 1353 334 350 120 1.402062E-06 1.116 N-46H 1360 1380 980 980 1353 350 366 120 1.408163E-06 1.121 N-48H 1380 1410 1010 1060 1353 366 382 120 1.330189E-06 1.059 N-30SH 1080 1140 810 860 1592 223 239 150 1.325581E-06 1.055 N-33SH 1140 1170 830 880 1592 239 263 150 1.329545E-06 1.058 N-35SH 1170 1220 870 920 1592 263 279 150 1.326087E-06 1.055 N-38SH 1220 1260 900 950 1592 279 303 150 1.326316E-06 1.055 N-40SH 1260 1300 930 980 1592 303 318 150 1.326531E-06 1.056 N-42SH 1300 1330 950 1000 1592 318 334 150 1.330000E-06 1.058 N-44SH 1330 1360 970 1020 1592 334 350 150 1.333333E-06 1.061 N-28UH 1040 1080 770 810 1989 199 223 180 1.333333E-06 1.061 N-30UH 1080 1140 810 860 1989 223 239 180 1.325581E-06 1.055 N-33UH 1140 1170 830 880 1989 239 263 180 1.329545E-06 1.058 N-35UH 1170 1220 870 920 1989 263 279 180 1.326087E-06 1.055 N-38UH 1220 1260 900 950 1989 279 303 180 1.326316E-06 1.055 N-40UH 1250 1280 900 950 1989 302 326 180 1.347368E-06 1.072 N-28EH 1040 1080 770 810 2387 199 223 200 1.333333E-06 1.061 N-30EH 1080 1140 810 860 2387 223 239 200 1.325581E-06 1.055 N-33EH 1140 1170 830 880 2387 239 263 200 1.329545E-06 1.058 N-35EH 1170 1220 870 920 2387 263 279 200 1.326087E-06 1.055 N-38EH 1220 1260 900 950 2387 279 303 200 1.326316E-06 1.055 N-25AH 970 1020 730 770 2787 180 200 220 1.324675E-06 1.054 N-28AH 1040 1080 770 810 2787 203 218 220 1.333333E-06 1.061 N-30AH 1080 1140 810 860 2787 220 250 220 1.325581E-06 1.055 N-25BH 950 1000 710 750 3000 170 190 230 1.333333E-06 1.061 Data upto temperature column from : http://www.goudsmitmagnets.com/magnets-assemblies/permanent-magnets/neodymium-magnets-ndfeb/neodymium-magnets-ndfeb Cheers, Gilles > De: "Gilles Qu?m?ner" > ?: "getdp" > Envoy?: Mercredi 9 Ao?t 2017 10:21:31 > Objet: Permanent magnet in GetDP > Hi, > When simulating permanent NdFeB magnets in a homemade BEM program, I use a > permeability of 1.05 and a remanent magnetization/field > depending on the magnet grade as given for instance in the following table : > Minimum Values > Grade Br Hc (Hcb) Hci (Hcj) BHmax > (T) (kA/m) (kA/m) (kJ/m?) > N27 1.030 796 955 199 > N30 1.080 796 955 223 > N33 1.130 836 955 247 > N35 1.170 867 955 263 > N38 1.210 899 955 287 > N40 1.240 923 955 302 > N42 1.280 923 955 318 > N45 1.320 875 955 342 > N48 1.380 836 875 366 > N50 1.400 796 875 382 > N52 1.430 796 875 398 > Looking closer to the magnet.xxx files in the GetDP demos folder, I cannot > figure out how the > remanent magnetization is taken into account as only Hc seems to be used in the > material definition. > I would think that both Hc and Br should be used. > How would one distinguish between N40 and N42 grades which have the same Hc > values ? How the fact > that an N50 magnet has a larger remanent field than an N40 one is accounted for > in GetDP when > Hc(N50) is smaller than Hc(N40) and equal to Hc(N27) ? > Thanks a lot for any hints, > Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From vskych at gmail.com Wed Aug 9 15:19:26 2017 From: vskych at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQpdC+0YDQvtGI0LXQsg==?=) Date: Wed, 9 Aug 2017 16:19:26 +0300 Subject: [Getdp] GetDP MPI versus single CPU In-Reply-To: <1761319893.9108.1502264747286.JavaMail.zimbra@lpccaen.in2p3.fr> References: <1761319893.9108.1502264747286.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: What versions of BLAS, MUMPS do you use? With what options was PETSc configured? Run getdp with "-cpu -v 8" options. If hang that repeat without "-cpu" Which processors do you use? 2017-08-09 10:45 GMT+03:00 gilles quemener : > Hi, > > I have compiled GetDP with MPI option under Linux Ubuntu 16.04 on a > machine w/ 6x2 CPUs and 32 MB of RAM. > When running the magnet.pro file given in the GetDP demos folder, I was > expecting to get faster results with MPI > than w/o and was quite surprise by the comparison as shown by the > following outputs : > > 1) MPI run: > *********** > > mpirun -np 12 /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet > -solve MagSta_phi -pos MagSta_phi > Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet > -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 12 nodes] > Info : Started (Wed Aug 9 09:20:20 2017, Wall = 0.277839s, CPU = > 0.884s [0.04s,0.116s], Mem = 287.254Mb [23.4609Mb,27.6289Mb]) > Info : Increasing process stack size (8192 kB < 16 MB) > Info : Loading problem definition 'magnet.pro' > Info : Loading problem definition 'magnet_data.pro' > Info : Loading problem definition '../templates/MaterialDatabase.pro' > Info : Loading problem definition '../templates/MaterialMacros.pro' > Info : Loading problem definition '../templates/Magnetostatics.pro' > Info : Selected Resolution 'MagSta_phi' > Info : Loading Geometric data 'magnet.msh' > Info : System 'A' : Real > P r e - P r o c e s s i n g . . . > Info : Treatment Formulation 'MagSta_phi' > Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) > Info : [rank 8] System 1/1: 1658225 Dofs > Info : [rank 7] System 1/1: 1658225 Dofs > Info : [rank 3] System 1/1: 1658225 Dofs > Info : [rank 4] System 1/1: 1658225 Dofs > Info : [rank 1] System 1/1: 1658225 Dofs > Info : [rank 2] System 1/1: 1658225 Dofs > Info : [rank 10] System 1/1: 1658225 Dofs > Info : [rank 6] System 1/1: 1658225 Dofs > Info : [rank 5] System 1/1: 1658225 Dofs > Info : [rank 11] System 1/1: 1658225 Dofs > Info : [rank 0] System 1/1: 1658225 Dofs > Info : [rank 9] System 1/1: 1658225 Dofs > Info : (Wall = 30.3178s, CPU = 181.936s [14.804s,16.964s], Mem = > 8228.93Mb [685.133Mb,689.43Mb]) > E n d P r e - P r o c e s s i n g > P r o c e s s i n g . . . > Info : CreateDir[../templates/res/] > Info : Generate[A] > Info : Solve[A] > Info : N: 1658225 - preonly lu mumps > Info : SaveSolution[A] > Info : (Wall = 87.9995s, CPU = 489.904s [38.456s,48.752s], Mem = > 14249.9Mb [1109.46Mb,1297.96Mb]) > E n d P r o c e s s i n g > P o s t - P r o c e s s i n g . . . > Info : NameOfSystem not set in PostProcessing: selected 'A' > Info : Selected PostProcessing 'MagSta_phi' > Info : Selected Mesh 'magnet.msh' > Info : PostOperation 1/4 > > 'res/MagSta_phi_hc.pos' > Info : PostOperation 2/4 > > > 'res/MagSta_phi_phi.pos' > Info : PostOperation 3/4 > > > 'res/MagSta_phi_h.pos' > Info : PostOperation 4/4 > > > 'res/MagSta_phi_b.pos' > Info : (Wall = 377.562s, CPU = 1118.17s [80.556s,207.128s], Mem = > 14254.1Mb [1109.95Mb,1297.96Mb]) > E n d P o s t - P r o c e s s i n g > Info : Stopped (Wed Aug 9 09:26:37 2017, Wall = 377.851s, CPU = > 2012.12s [162.712s,207.26s], Mem = 14254.1Mb [1109.95Mb,1297.96Mb]) > > > 2) Single CPU run: > ****************** > > /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi > -pos MagSta_phi > Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet > -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 1 node] > Info : Started (Wed Aug 9 09:27:06 2017, Wall = 0.146171s, CPU = > 0.136s, Mem = 25.9609Mb) > Info : Increasing process stack size (8192 kB < 16 MB) > Info : Loading problem definition 'magnet.pro' > Info : Loading problem definition 'magnet_data.pro' > Info : Loading problem definition '../templates/MaterialDatabase.pro' > Info : Loading problem definition '../templates/MaterialMacros.pro' > Info : Loading problem definition '../templates/Magnetostatics.pro' > Info : Selected Resolution 'MagSta_phi' > Info : Loading Geometric data 'magnet.msh' > Info : System 'A' : Real > P r e - P r o c e s s i n g . . . > Info : Treatment Formulation 'MagSta_phi' > Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) > Info : System 1/1: 1658225 Dofs > Info : (Wall = 10.7856s, CPU = 7.42s, Mem = 688.309Mb) > E n d P r e - P r o c e s s i n g > P r o c e s s i n g . . . > Info : CreateDir[../templates/res/] > Info : Generate[A] > Info : Solve[A] > Info : N: 1658225 - preonly lu mumps > Info : SaveSolution[A] > Info : (Wall = 40.7256s, CPU = 47.028s, Mem = 4496.32Mb) > E n d P r o c e s s i n g > P o s t - P r o c e s s i n g . . . > Info : NameOfSystem not set in PostProcessing: selected 'A' > Info : Selected PostProcessing 'MagSta_phi' > Info : Selected Mesh 'magnet.msh' > Info : PostOperation 1/4 > > 'res/MagSta_phi_hc.pos' > Info : PostOperation 2/4 > > > 'res/MagSta_phi_phi.pos' > Info : PostOperation 3/4 > > > 'res/MagSta_phi_h.pos' > Info : PostOperation 4/4 > > > 'res/MagSta_phi_b.pos' > Info : (Wall = 324.758s, CPU = 132.924s, Mem = > 4496.32Mb) > E n d P o s t - P r o c e s s i n g > Info : Stopped (Wed Aug 9 09:32:31 2017, Wall = 324.946s, CPU = > 133.032s, Mem = 4496.32Mb) > > Does any one has clues to explain such a behaviour ? > > Gilles > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From funkybob at gmail.com Wed Aug 9 16:37:12 2017 From: funkybob at gmail.com (Jasper) Date: Wed, 9 Aug 2017 16:37:12 +0200 Subject: [Getdp] Permanent magnet in GetDP In-Reply-To: <473537205.10740.1502272506886.JavaMail.zimbra@lpccaen.in2p3.fr> References: <1233082569.9591.1502266891190.JavaMail.zimbra@lpccaen.in2p3.fr> <473537205.10740.1502272506886.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: Hi Gilles, Your suggestion is typically the way I've done it in the past, specify by HcB and mu_r. From my understanding, in a NdFeB magnet at low temperatures this linear relation should be valid and the results have appear plausible so far :-) Keep in mind that once the relatively small difference between e.g. N40 and N42 starts to matter in your simulation you should really consult your magnet supplier as the magnets typically have tolerances and are also not completely homogenous etc... Best regards, Jasper On Wed, Aug 9, 2017 at 11:55 AM, gilles quemener wrote: > Hi, > > Following my previous message, I digged more into the .pro files of GetDP > demos magnet.xxx > and it seems that one could perhaps use both Hc and ?_r to distinguish > between NdFeB magnets grades. > In GetDP demos, the permanent magnets material could be defined as in > MaterialDatabase.pro w/ > the following lines : > > // NdFeB magnet N45 > Materials() += Str[ "NdFeB_Grade_N45" ]; > NdFeB_mur = 1.172; // Br = 1370 mT, Hcb = 930000 A/m and ?_r = Br / Hcb > / ?_o > NdFeB_sigma = 2e5; > NdFeB_hc = 930000; > > where ?_r and Hcb values have been taken from the ttypical table below. > Could anyone confirm or infirm this approach ? > > > Remanence > coercivity > coercivity > product > > > > Br > Hcb > Hcj > B H max > ? = Br / Hcb ?_r= ? / ?o > > mT > kA/m > kA/m > kJ/m3 > T/A/m > > > min typ min typ min min typ ?C > > N-35 1170 1120 870 920 955 263 279 80 1.217391E-06 0.969 > N-38 1220 1260 870 920 955 279 303 80 1.369565E-06 1.090 > N-40 1260 1300 870 920 955 303 318 80 1.413043E-06 1.124 > N-42 1300 1330 870 920 955 318 334 80 1.445652E-06 1.150 > N-45 1330 1370 900 930 955 334 358 80 1.473118E-06 1.172 > N-48 1370 1410 900 930 875 358 382 80 1.516129E-06 1.206 > N-50 1410 1440 830 850 875 382 398 80 1.694118E-06 1.348 > N-52 1430 1480 820 840 875 398 422 80 1.761905E-06 1.402 > N-33M 1140 1170 830 859 1114 239 263 100 1.362049E-06 1.084 > N-35M 1170 1220 870 891 1114 263 279 100 1.369248E-06 1.090 > N-38M 1220 1260 900 915 1114 279 303 100 1.377049E-06 1.096 > N-40M 1260 1300 930 915 1114 303 318 100 1.420765E-06 1.131 > N-42M 1300 1330 950 915 1114 318 334 100 1.453552E-06 1.157 > N-45M 1330 1370 980 915 1114 334 358 100 1.497268E-06 1.191 > N-48M 1370 1410 1010 980 1114 358 382 90 1.438776E-06 1.145 > N-50M 1410 1440 1030 980 1114 382 398 90 1.469388E-06 1.169 > N-30H 1080 1140 810 810 1353 223 239 120 1.407407E-06 1.120 > N-33H 1140 1170 830 830 1353 239 263 120 1.409639E-06 1.122 > N-35H 1170 1220 870 870 1353 263 279 120 1.402299E-06 1.116 > N-38H 1220 1260 900 900 1353 279 303 120 1.400000E-06 1.114 > N-40H 1260 1300 930 930 1353 303 318 120 1.397849E-06 1.112 > N-42H 1300 1330 950 950 1353 318 334 120 1.400000E-06 1.114 > N-44H 1330 1360 970 970 1353 334 350 120 1.402062E-06 1.116 > N-46H 1360 1380 980 980 1353 350 366 120 1.408163E-06 1.121 > N-48H 1380 1410 1010 1060 1353 366 382 120 1.330189E-06 1.059 > N-30SH 1080 1140 810 860 1592 223 239 150 1.325581E-06 1.055 > N-33SH 1140 1170 830 880 1592 239 263 150 1.329545E-06 1.058 > N-35SH 1170 1220 870 920 1592 263 279 150 1.326087E-06 1.055 > N-38SH 1220 1260 900 950 1592 279 303 150 1.326316E-06 1.055 > N-40SH 1260 1300 930 980 1592 303 318 150 1.326531E-06 1.056 > N-42SH 1300 1330 950 1000 1592 318 334 150 1.330000E-06 1.058 > N-44SH 1330 1360 970 1020 1592 334 350 150 1.333333E-06 1.061 > N-28UH 1040 1080 770 810 1989 199 223 180 1.333333E-06 1.061 > N-30UH 1080 1140 810 860 1989 223 239 180 1.325581E-06 1.055 > N-33UH 1140 1170 830 880 1989 239 263 180 1.329545E-06 1.058 > N-35UH 1170 1220 870 920 1989 263 279 180 1.326087E-06 1.055 > N-38UH 1220 1260 900 950 1989 279 303 180 1.326316E-06 1.055 > N-40UH 1250 1280 900 950 1989 302 326 180 1.347368E-06 1.072 > N-28EH 1040 1080 770 810 2387 199 223 200 1.333333E-06 1.061 > N-30EH 1080 1140 810 860 2387 223 239 200 1.325581E-06 1.055 > N-33EH 1140 1170 830 880 2387 239 263 200 1.329545E-06 1.058 > N-35EH 1170 1220 870 920 2387 263 279 200 1.326087E-06 1.055 > N-38EH 1220 1260 900 950 2387 279 303 200 1.326316E-06 1.055 > N-25AH 970 1020 730 770 2787 180 200 220 1.324675E-06 1.054 > N-28AH 1040 1080 770 810 2787 203 218 220 1.333333E-06 1.061 > N-30AH 1080 1140 810 860 2787 220 250 220 1.325581E-06 1.055 > N-25BH 950 1000 710 750 3000 170 190 230 1.333333E-06 1.061 > Data upto temperature column from : > > > > > > > > > > http://www.goudsmitmagnets.com/magnets-assemblies/ > permanent-magnets/neodymium-magnets-ndfeb/neodymium-magnets-ndfeb > > > > > > > > > > > Cheers, > > Gilles > > > > > ------------------------------ > > *De: *"Gilles Qu?m?ner" > *?: *"getdp" > *Envoy?: *Mercredi 9 Ao?t 2017 10:21:31 > *Objet: *Permanent magnet in GetDP > > Hi, > > When simulating permanent NdFeB magnets in a homemade BEM program, I use a > permeability of 1.05 and a remanent magnetization/field > depending on the magnet grade as given for instance in the following table > : > > Minimum Values > Grade Br Hc (Hcb) Hci (Hcj) BHmax > (T) (kA/m) (kA/m) (kJ/m?) > N27 1.030 796 955 199 > N30 1.080 796 955 223 > N33 1.130 836 955 247 > N35 1.170 867 955 263 > N38 1.210 899 955 287 > N40 1.240 923 955 302 > N42 1.280 923 955 318 > N45 1.320 875 955 342 > N48 1.380 836 875 366 > N50 1.400 796 875 382 > N52 1.430 796 875 398 > > Looking closer to the magnet.xxx files in the GetDP demos folder, I cannot > figure out how the > remanent magnetization is taken into account as only Hc seems to be used > in the material definition. > I would think that both Hc and Br should be used. > How would one distinguish between N40 and N42 grades which have the same > Hc values ? How the fact > that an N50 magnet has a larger remanent field than an N40 one is > accounted for in GetDP when > Hc(N50) is smaller than Hc(N40) and equal to Hc(N27) ? > > Thanks a lot for any hints, > > Gilles > > > > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vskych at gmail.com Wed Aug 9 17:09:09 2017 From: vskych at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQpdC+0YDQvtGI0LXQsg==?=) Date: Wed, 9 Aug 2017 18:09:09 +0300 Subject: [Getdp] GetDP MPI versus single CPU In-Reply-To: <390328266.17805.1502287233045.JavaMail.zimbra@lpccaen.in2p3.fr> References: <1761319893.9108.1502264747286.JavaMail.zimbra@lpccaen.in2p3.fr> <390328266.17805.1502287233045.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: Hi. First a couple of tips on improving performance. 1) Generic BLAS slow enough. Try using ATLAS, OpenBLAS or MKL (preferably for INTEL) or etc. 2) The use of MPI ("mpirun") can have many nuances (for example, multiple performance degradation in the "Generate" operation with some large unsymmetrical matrices). Use it with caution or use the OpenMP instead (it is only possible for the factorization phase). See, for example, OpenBLAS or ACML or <...> documentation. 3) For symmetric matrices, use the "cholesky" instead of "lu" (also see MUMPS and PETSc user manual). Concerning your problem. Preprocessing ("-pre") and postprocessing ("-pos") use only one thread. Using "mpirun" on these operations leads to a decrease in performance. Use of MPI ("mpirun") allows to obtain a gain only in the processing operation ("-cal"). In this case, different combinations of implementations of the BLAS and hardware (various CPUs) can give a sharp decrease in performance if the number of threads ("-np N") exceeds Cores / 2. Try to fulfill this condition, for example "mpirun -np 2 getdp magnet -cal -cpu". Compare the time between "SaveSolution [A]" and "Solve [A]" ("Wall" time) with this time on 1 thread ("getdp magnet -cal -cpu"). P.S. I have no relationship to the development of this software (or libraries used by it) and I have only little knowledge of higher mathematics. Almost all the information that I have given is received, mainly empirically and from the documentation for this software. I hope that my information will help you. In my case, I do not use MPI in its pure form. I use OpenBLAS or ACML (for different hardware) that use OpenMP, which allows several threads to be used for the factorization phase (I use "mpirun" only in some cases). And, > Looking at your mail it seems that I might have to recompile BLAS, MUMPS > and PETSC with particular options ? In Ubuntu you can use "sudo apt install openblas*" (for example) and recompilation is not required due to "update-alternatives" (but in some cases it not working). After that you can use "OMP_NUM_THREADS=" environment variable to set number of threads (work only in factorization phase of "Solve[A]" operation). 2017-08-09 17:00 GMT+03:00 gilles quemener : > Hi, > > For BLAS, MUMPS and PETSC, I am using standard packages from Ubuntu 16.04 > with the following versions: > - BLAS : libblas 3.6.0 > - MUMPS: libmumps 4.10.0 > - PETSC: libpetsc 3.6.2 > I do not know the standard compiling options from Ubuntu 16.04 for these > packages. > > For the processors, from /proc/cpuinfo: > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 63 > model name : Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz > stepping : 2 > microcode : 0x2d > cpu MHz : 1199.988 > cache size : 15360 KB > > > Looking at your mail it seems that I might have to recompile BLAS, MUMPS >> and PETSC with particular options ? > > If yes, which versions of these programs (especially for BLAS which can be > found in many libraries) do you suggest to use ? > > Results from running getdp w/ options -cpu -v8 is in attached file > singleCPU.txt. > > Thanks a lot for your help. > > Gilles > > > ------------------------------ > > *De: *"????? ???????" > *?: *"Gilles Qu?m?ner" > *Cc: *"getdp" > *Envoy?: *Mercredi 9 Ao?t 2017 15:19:26 > *Objet: *Re: [Getdp] GetDP MPI versus single CPU > > What versions of BLAS, MUMPS do you use? > With what options was PETSc configured? > Run getdp with "-cpu -v 8" options. If hang that repeat without "-cpu" > Which processors do you use? > > 2017-08-09 10:45 GMT+03:00 gilles quemener : > >> Hi, >> >> I have compiled GetDP with MPI option under Linux Ubuntu 16.04 on a >> machine w/ 6x2 CPUs and 32 MB of RAM. >> When running the magnet.pro file given in the GetDP demos folder, I was >> expecting to get faster results with MPI >> than w/o and was quite surprise by the comparison as shown by the >> following outputs : >> >> 1) MPI run: >> *********** >> >> mpirun -np 12 /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet >> -solve MagSta_phi -pos MagSta_phi >> Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet >> -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 12 nodes] >> Info : Started (Wed Aug 9 09:20:20 2017, Wall = 0.277839s, CPU = >> 0.884s [0.04s,0.116s], Mem = 287.254Mb [23.4609Mb,27.6289Mb]) >> Info : Increasing process stack size (8192 kB < 16 MB) >> Info : Loading problem definition 'magnet.pro' >> Info : Loading problem definition 'magnet_data.pro' >> Info : Loading problem definition '../templates/MaterialDatabase.pro' >> Info : Loading problem definition '../templates/MaterialMacros.pro' >> Info : Loading problem definition '../templates/Magnetostatics.pro' >> Info : Selected Resolution 'MagSta_phi' >> Info : Loading Geometric data 'magnet.msh' >> Info : System 'A' : Real >> P r e - P r o c e s s i n g . . . >> Info : Treatment Formulation 'MagSta_phi' >> Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) >> Info : [rank 8] System 1/1: 1658225 Dofs >> Info : [rank 7] System 1/1: 1658225 Dofs >> Info : [rank 3] System 1/1: 1658225 Dofs >> Info : [rank 4] System 1/1: 1658225 Dofs >> Info : [rank 1] System 1/1: 1658225 Dofs >> Info : [rank 2] System 1/1: 1658225 Dofs >> Info : [rank 10] System 1/1: 1658225 Dofs >> Info : [rank 6] System 1/1: 1658225 Dofs >> Info : [rank 5] System 1/1: 1658225 Dofs >> Info : [rank 11] System 1/1: 1658225 Dofs >> Info : [rank 0] System 1/1: 1658225 Dofs >> Info : [rank 9] System 1/1: 1658225 Dofs >> Info : (Wall = 30.3178s, CPU = 181.936s [14.804s,16.964s], Mem = >> 8228.93Mb [685.133Mb,689.43Mb]) >> E n d P r e - P r o c e s s i n g >> P r o c e s s i n g . . . >> Info : CreateDir[../templates/res/] >> Info : Generate[A] >> Info : Solve[A] >> Info : N: 1658225 - preonly lu mumps >> Info : SaveSolution[A] >> Info : (Wall = 87.9995s, CPU = 489.904s [38.456s,48.752s], Mem = >> 14249.9Mb [1109.46Mb,1297.96Mb]) >> E n d P r o c e s s i n g >> P o s t - P r o c e s s i n g . . . >> Info : NameOfSystem not set in PostProcessing: selected 'A' >> Info : Selected PostProcessing 'MagSta_phi' >> Info : Selected Mesh 'magnet.msh' >> Info : PostOperation 1/4 >> > 'res/MagSta_phi_hc.pos' >> Info : PostOperation 2/4 >> >> > 'res/MagSta_phi_phi.pos' >> Info : PostOperation 3/4 >> >> > 'res/MagSta_phi_h.pos' >> Info : PostOperation 4/4 >> >> > 'res/MagSta_phi_b.pos' >> Info : (Wall = 377.562s, CPU = 1118.17s [80.556s,207.128s], Mem = >> 14254.1Mb [1109.95Mb,1297.96Mb]) >> E n d P o s t - P r o c e s s i n g >> Info : Stopped (Wed Aug 9 09:26:37 2017, Wall = 377.851s, CPU = >> 2012.12s [162.712s,207.26s], Mem = 14254.1Mb [1109.95Mb,1297.96Mb]) >> >> >> 2) Single CPU run: >> ****************** >> >> /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi >> -pos MagSta_phi >> Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet >> -solve MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 1 node] >> Info : Started (Wed Aug 9 09:27:06 2017, Wall = 0.146171s, CPU = >> 0.136s, Mem = 25.9609Mb) >> Info : Increasing process stack size (8192 kB < 16 MB) >> Info : Loading problem definition 'magnet.pro' >> Info : Loading problem definition 'magnet_data.pro' >> Info : Loading problem definition '../templates/MaterialDatabase.pro' >> Info : Loading problem definition '../templates/MaterialMacros.pro' >> Info : Loading problem definition '../templates/Magnetostatics.pro' >> Info : Selected Resolution 'MagSta_phi' >> Info : Loading Geometric data 'magnet.msh' >> Info : System 'A' : Real >> P r e - P r o c e s s i n g . . . >> Info : Treatment Formulation 'MagSta_phi' >> Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) >> Info : System 1/1: 1658225 Dofs >> Info : (Wall = 10.7856s, CPU = 7.42s, Mem = 688.309Mb) >> E n d P r e - P r o c e s s i n g >> P r o c e s s i n g . . . >> Info : CreateDir[../templates/res/] >> Info : Generate[A] >> Info : Solve[A] >> >> Info : N: 1658225 - preonly lu mumps >> Info : SaveSolution[A] >> Info : (Wall = 40.7256s, CPU = 47.028s, Mem = 4496.32Mb) >> E n d P r o c e s s i n g >> P o s t - P r o c e s s i n g . . . >> Info : NameOfSystem not set in PostProcessing: selected 'A' >> Info : Selected PostProcessing 'MagSta_phi' >> Info : Selected Mesh 'magnet.msh' >> Info : PostOperation 1/4 >> > 'res/MagSta_phi_hc.pos' >> Info : PostOperation 2/4 >> >> > 'res/MagSta_phi_phi.pos' >> Info : PostOperation 3/4 >> >> > 'res/MagSta_phi_h.pos' >> Info : PostOperation 4/4 >> >> > 'res/MagSta_phi_b.pos' >> Info : (Wall = 324.758s, CPU = 132.924s, Mem = >> 4496.32Mb) >> E n d P o s t - P r o c e s s i n g >> Info : Stopped (Wed Aug 9 09:32:31 2017, Wall = 324.946s, CPU = >> 133.032s, Mem = 4496.32Mb) >> >> Does any one has clues to explain such a behaviour ? >> >> Gilles >> >> >> _______________________________________________ >> getdp mailing list >> getdp at onelab.info >> http://onelab.info/mailman/listinfo/getdp >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quemener at lpccaen.in2p3.fr Wed Aug 9 16:00:33 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Wed, 9 Aug 2017 16:00:33 +0200 (CEST) Subject: [Getdp] GetDP MPI versus single CPU In-Reply-To: References: <1761319893.9108.1502264747286.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: <390328266.17805.1502287233045.JavaMail.zimbra@lpccaen.in2p3.fr> Hi, For BLAS, MUMPS and PETSC, I am using standard packages from Ubuntu 16.04 with the following versions: - BLAS : libblas 3.6.0 - MUMPS: libmumps 4.10.0 - PETSC: libpetsc 3.6.2 I do not know the standard compiling options from Ubuntu 16.04 for these packages. For the processors, from /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz stepping : 2 microcode : 0x2d cpu MHz : 1199.988 cache size : 15360 KB Looking at your mail it seems that I might have to recompile BLAS, MUMPS and PETSC with particular options ? If yes, which versions of these programs (especially for BLAS which can be found in many libraries) do you suggest to use ? Results from running getdp w/ options -cpu -v8 is in attached file singleCPU.txt. Thanks a lot for your help. Gilles > De: "????? ???????" > ?: "Gilles Qu?m?ner" > Cc: "getdp" > Envoy?: Mercredi 9 Ao?t 2017 15:19:26 > Objet: Re: [Getdp] GetDP MPI versus single CPU > What versions of BLAS, MUMPS do you use? > With what options was PETSc configured? > Run getdp with "-cpu -v 8" options. If hang that repeat without "-cpu" > Which processors do you use? > 2017-08-09 10:45 GMT+03:00 gilles quemener < [ mailto:quemener at lpccaen.in2p3.fr > | quemener at lpccaen.in2p3.fr ] > : >> Hi, >> I have compiled GetDP with MPI option under Linux Ubuntu 16.04 on a machine w/ >> 6x2 CPUs and 32 MB of RAM. >> When running the [ http://magnet.pro/ | magnet.pro ] file given in the GetDP >> demos folder, I was expecting to get faster results with MPI >> than w/o and was quite surprise by the comparison as shown by the following >> outputs : >> 1) MPI run: >> *********** >> mpirun -np 12 /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve >> MagSta_phi -pos MagSta_phi >> Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve >> MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 12 nodes] >> Info : Started (Wed Aug 9 09:20:20 2017, Wall = 0.277839s, CPU = 0.884s >> [0.04s,0.116s], Mem = 287.254Mb [23.4609Mb,27.6289Mb]) >> Info : Increasing process stack size (8192 kB < 16 MB) >> Info : Loading problem definition ' [ http://magnet.pro/ | magnet.pro ] ' >> Info : Loading problem definition ' [ http://magnet_data.pro/ | magnet_data.pro >> ] ' >> Info : Loading problem definition '../templates/MaterialDatabase.pro' >> Info : Loading problem definition '../templates/MaterialMacros.pro' >> Info : Loading problem definition '../templates/Magnetostatics.pro' >> Info : Selected Resolution 'MagSta_phi' >> Info : Loading Geometric data 'magnet.msh' >> Info : System 'A' : Real >> P r e - P r o c e s s i n g . . . >> Info : Treatment Formulation 'MagSta_phi' >> Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) >> Info : [rank 8] System 1/1: 1658225 Dofs >> Info : [rank 7] System 1/1: 1658225 Dofs >> Info : [rank 3] System 1/1: 1658225 Dofs >> Info : [rank 4] System 1/1: 1658225 Dofs >> Info : [rank 1] System 1/1: 1658225 Dofs >> Info : [rank 2] System 1/1: 1658225 Dofs >> Info : [rank 10] System 1/1: 1658225 Dofs >> Info : [rank 6] System 1/1: 1658225 Dofs >> Info : [rank 5] System 1/1: 1658225 Dofs >> Info : [rank 11] System 1/1: 1658225 Dofs >> Info : [rank 0] System 1/1: 1658225 Dofs >> Info : [rank 9] System 1/1: 1658225 Dofs >> Info : (Wall = 30.3178s, CPU = 181.936s [14.804s,16.964s], Mem = 8228.93Mb >> [685.133Mb,689.43Mb]) >> E n d P r e - P r o c e s s i n g >> P r o c e s s i n g . . . >> Info : CreateDir[../templates/res/] >> Info : Generate[A] >> Info : Solve[A] >> Info : N: 1658225 - preonly lu mumps >> Info : SaveSolution[A] >> Info : (Wall = 87.9995s, CPU = 489.904s [38.456s,48.752s], Mem = 14249.9Mb >> [1109.46Mb,1297.96Mb]) >> E n d P r o c e s s i n g >> P o s t - P r o c e s s i n g . . . >> Info : NameOfSystem not set in PostProcessing: selected 'A' >> Info : Selected PostProcessing 'MagSta_phi' >> Info : Selected Mesh 'magnet.msh' >> Info : PostOperation 1/4 >> > 'res/MagSta_phi_hc.pos' >> Info : PostOperation 2/4 >> > 'res/MagSta_phi_phi.pos' >> Info : PostOperation 3/4 >> > 'res/MagSta_phi_h.pos' >> Info : PostOperation 4/4 >> > 'res/MagSta_phi_b.pos' >> Info : (Wall = 377.562s, CPU = 1118.17s [80.556s,207.128s], Mem = 14254.1Mb >> [1109.95Mb,1297.96Mb]) >> E n d P o s t - P r o c e s s i n g >> Info : Stopped (Wed Aug 9 09:26:37 2017, Wall = 377.851s, CPU = 2012.12s >> [162.712s,207.26s], Mem = 14254.1Mb [1109.95Mb,1297.96Mb]) >> 2) Single CPU run: >> ****************** >> /home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve MagSta_phi -pos >> MagSta_phi >> Info : Running '/home/quemener/local/OneLab_gq/GetDP/bin/getdp magnet -solve >> MagSta_phi -pos MagSta_phi' [GetDP 2.11.1, 1 node] >> Info : Started (Wed Aug 9 09:27:06 2017, Wall = 0.146171s, CPU = 0.136s, Mem = >> 25.9609Mb) >> Info : Increasing process stack size (8192 kB < 16 MB) >> Info : Loading problem definition ' [ http://magnet.pro/ | magnet.pro ] ' >> Info : Loading problem definition ' [ http://magnet_data.pro/ | magnet_data.pro >> ] ' >> Info : Loading problem definition '../templates/MaterialDatabase.pro' >> Info : Loading problem definition '../templates/MaterialMacros.pro' >> Info : Loading problem definition '../templates/Magnetostatics.pro' >> Info : Selected Resolution 'MagSta_phi' >> Info : Loading Geometric data 'magnet.msh' >> Info : System 'A' : Real >> P r e - P r o c e s s i n g . . . >> Info : Treatment Formulation 'MagSta_phi' >> Info : Generate ExtendedGroup '_CO_Entity_15' (NodesOf) >> Info : System 1/1: 1658225 Dofs >> Info : (Wall = 10.7856s, CPU = 7.42s, Mem = 688.309Mb) >> E n d P r e - P r o c e s s i n g >> P r o c e s s i n g . . . >> Info : CreateDir[../templates/res/] >> Info : Generate[A] >> Info : Solve[A] >> Info : N: 1658225 - preonly lu mumps >> Info : SaveSolution[A] >> Info : (Wall = 40.7256s, CPU = 47.028s, Mem = 4496.32Mb) >> E n d P r o c e s s i n g >> P o s t - P r o c e s s i n g . . . >> Info : NameOfSystem not set in PostProcessing: selected 'A' >> Info : Selected PostProcessing 'MagSta_phi' >> Info : Selected Mesh 'magnet.msh' >> Info : PostOperation 1/4 >> > 'res/MagSta_phi_hc.pos' >> Info : PostOperation 2/4 >> > 'res/MagSta_phi_phi.pos' >> Info : PostOperation 3/4 >> > 'res/MagSta_phi_h.pos' >> Info : PostOperation 4/4 >> > 'res/MagSta_phi_b.pos' >> Info : (Wall = 324.758s, CPU = 132.924s, Mem = 4496.32Mb) >> E n d P o s t - P r o c e s s i n g >> Info : Stopped (Wed Aug 9 09:32:31 2017, Wall = 324.946s, CPU = 133.032s, Mem = >> 4496.32Mb) >> Does any one has clues to explain such a behaviour ? >> Gilles >> _______________________________________________ >> getdp mailing list >> [ mailto:getdp at onelab.info | getdp at onelab.info ] >> [ http://onelab.info/mailman/listinfo/getdp | >> http://onelab.info/mailman/listinfo/getdp ] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: singleCPU.txt URL: From quemener at lpccaen.in2p3.fr Wed Aug 9 16:45:38 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Wed, 9 Aug 2017 16:45:38 +0200 (CEST) Subject: [Getdp] Permanent magnet in GetDP In-Reply-To: References: <1233082569.9591.1502266891190.JavaMail.zimbra@lpccaen.in2p3.fr> <473537205.10740.1502272506886.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: <686077231.18175.1502289938170.JavaMail.zimbra@lpccaen.in2p3.fr> Hi Jasper, Thanks for your answer. This is a good news ! However, at lunch time I thought about it a bit more and figured out that one has to take into account the fact that a permanent magnet is anisotropic and therefore we should use a permeability tensor instead of a scalar constant ... this will make the formulation much more complicated ! Cheers, Gilles > De: "Jasper" > ?: "Gilles Qu?m?ner" > Cc: "getdp" > Envoy?: Mercredi 9 Ao?t 2017 16:37:12 > Objet: Re: [Getdp] Permanent magnet in GetDP > Hi Gilles, > Your suggestion is typically the way I've done it in the past, specify by HcB > and mu_r. From my understanding, in a NdFeB magnet at low temperatures this > linear relation should be valid and the results have appear plausible so far > :-) > Keep in mind that once the relatively small difference between e.g. N40 and N42 > starts to matter in your simulation you should really consult your magnet > supplier as the magnets typically have tolerances and are also not completely > homogenous etc... > Best regards, > Jasper > On Wed, Aug 9, 2017 at 11:55 AM, gilles quemener < [ > mailto:quemener at lpccaen.in2p3.fr | quemener at lpccaen.in2p3.fr ] > wrote: >> Hi, >> Following my previous message, I digged more into the .pro files of GetDP demos >> magnet.xxx >> and it seems that one could perhaps use both Hc and ?_r to distinguish between >> NdFeB magnets grades. >> In GetDP demos, the permanent magnets material could be defined as in >> MaterialDatabase.pro w/ >> the following lines : >> // NdFeB magnet N45 >> Materials() += Str[ "NdFeB_Grade_N45" ]; >> NdFeB_mur = 1.172; // Br = 1370 mT, Hcb = 930000 A/m and ?_r = Br / Hcb / ?_o >> NdFeB_sigma = 2e5; >> NdFeB_hc = 930000; >> where ?_r and Hcb values have been taken from the ttypical table below. >> Could anyone confirm or infirm this approach ? >> Remanence >> coercivity >> coercivity >> product >> Br >> Hcb >> Hcj >> B H max >> ? = Br / Hcb ?_r= ? / ?o >> mT >> kA/m >> kA/m >> kJ/m3 >> T/A/m >> min typ min typ min min typ ?C >> N-35 1170 1120 870 920 955 263 279 80 1.217391E-06 0.969 >> N-38 1220 1260 870 920 955 279 303 80 1.369565E-06 1.090 >> N-40 1260 1300 870 920 955 303 318 80 1.413043E-06 1.124 >> N-42 1300 1330 870 920 955 318 334 80 1.445652E-06 1.150 >> N-45 1330 1370 900 930 955 334 358 80 1.473118E-06 1.172 >> N-48 1370 1410 900 930 875 358 382 80 1.516129E-06 1.206 >> N-50 1410 1440 830 850 875 382 398 80 1.694118E-06 1.348 >> N-52 1430 1480 820 840 875 398 422 80 1.761905E-06 1.402 >> N-33M 1140 1170 830 859 1114 239 263 100 1.362049E-06 1.084 >> N-35M 1170 1220 870 891 1114 263 279 100 1.369248E-06 1.090 >> N-38M 1220 1260 900 915 1114 279 303 100 1.377049E-06 1.096 >> N-40M 1260 1300 930 915 1114 303 318 100 1.420765E-06 1.131 >> N-42M 1300 1330 950 915 1114 318 334 100 1.453552E-06 1.157 >> N-45M 1330 1370 980 915 1114 334 358 100 1.497268E-06 1.191 >> N-48M 1370 1410 1010 980 1114 358 382 90 1.438776E-06 1.145 >> N-50M 1410 1440 1030 980 1114 382 398 90 1.469388E-06 1.169 >> N-30H 1080 1140 810 810 1353 223 239 120 1.407407E-06 1.120 >> N-33H 1140 1170 830 830 1353 239 263 120 1.409639E-06 1.122 >> N-35H 1170 1220 870 870 1353 263 279 120 1.402299E-06 1.116 >> N-38H 1220 1260 900 900 1353 279 303 120 1.400000E-06 1.114 >> N-40H 1260 1300 930 930 1353 303 318 120 1.397849E-06 1.112 >> N-42H 1300 1330 950 950 1353 318 334 120 1.400000E-06 1.114 >> N-44H 1330 1360 970 970 1353 334 350 120 1.402062E-06 1.116 >> N-46H 1360 1380 980 980 1353 350 366 120 1.408163E-06 1.121 >> N-48H 1380 1410 1010 1060 1353 366 382 120 1.330189E-06 1.059 >> N-30SH 1080 1140 810 860 1592 223 239 150 1.325581E-06 1.055 >> N-33SH 1140 1170 830 880 1592 239 263 150 1.329545E-06 1.058 >> N-35SH 1170 1220 870 920 1592 263 279 150 1.326087E-06 1.055 >> N-38SH 1220 1260 900 950 1592 279 303 150 1.326316E-06 1.055 >> N-40SH 1260 1300 930 980 1592 303 318 150 1.326531E-06 1.056 >> N-42SH 1300 1330 950 1000 1592 318 334 150 1.330000E-06 1.058 >> N-44SH 1330 1360 970 1020 1592 334 350 150 1.333333E-06 1.061 >> N-28UH 1040 1080 770 810 1989 199 223 180 1.333333E-06 1.061 >> N-30UH 1080 1140 810 860 1989 223 239 180 1.325581E-06 1.055 >> N-33UH 1140 1170 830 880 1989 239 263 180 1.329545E-06 1.058 >> N-35UH 1170 1220 870 920 1989 263 279 180 1.326087E-06 1.055 >> N-38UH 1220 1260 900 950 1989 279 303 180 1.326316E-06 1.055 >> N-40UH 1250 1280 900 950 1989 302 326 180 1.347368E-06 1.072 >> N-28EH 1040 1080 770 810 2387 199 223 200 1.333333E-06 1.061 >> N-30EH 1080 1140 810 860 2387 223 239 200 1.325581E-06 1.055 >> N-33EH 1140 1170 830 880 2387 239 263 200 1.329545E-06 1.058 >> N-35EH 1170 1220 870 920 2387 263 279 200 1.326087E-06 1.055 >> N-38EH 1220 1260 900 950 2387 279 303 200 1.326316E-06 1.055 >> N-25AH 970 1020 730 770 2787 180 200 220 1.324675E-06 1.054 >> N-28AH 1040 1080 770 810 2787 203 218 220 1.333333E-06 1.061 >> N-30AH 1080 1140 810 860 2787 220 250 220 1.325581E-06 1.055 >> N-25BH 950 1000 710 750 3000 170 190 230 1.333333E-06 1.061 >> Data upto temperature column from : >> [ >> http://www.goudsmitmagnets.com/magnets-assemblies/permanent-magnets/neodymium-magnets-ndfeb/neodymium-magnets-ndfeb >> | >> http://www.goudsmitmagnets.com/magnets-assemblies/permanent-magnets/neodymium-magnets-ndfeb/neodymium-magnets-ndfeb >> ] >> Cheers, >> Gilles >>> De: "Gilles Qu?m?ner" < [ mailto:quemener at lpccaen.in2p3.fr | >>> quemener at lpccaen.in2p3.fr ] > >>> ?: "getdp" < [ mailto:getdp at onelab.info | getdp at onelab.info ] > >>> Envoy?: Mercredi 9 Ao?t 2017 10:21:31 >>> Objet: Permanent magnet in GetDP >>> Hi, >>> When simulating permanent NdFeB magnets in a homemade BEM program, I use a >>> permeability of 1.05 and a remanent magnetization/field >>> depending on the magnet grade as given for instance in the following table : >>> Minimum Values >>> Grade Br Hc (Hcb) Hci (Hcj) BHmax >>> (T) (kA/m) (kA/m) (kJ/m?) >>> N27 1.030 796 955 199 >>> N30 1.080 796 955 223 >>> N33 1.130 836 955 247 >>> N35 1.170 867 955 263 >>> N38 1.210 899 955 287 >>> N40 1.240 923 955 302 >>> N42 1.280 923 955 318 >>> N45 1.320 875 955 342 >>> N48 1.380 836 875 366 >>> N50 1.400 796 875 382 >>> N52 1.430 796 875 398 >>> Looking closer to the magnet.xxx files in the GetDP demos folder, I cannot >>> figure out how the >>> remanent magnetization is taken into account as only Hc seems to be used in the >>> material definition. >>> I would think that both Hc and Br should be used. >>> How would one distinguish between N40 and N42 grades which have the same Hc >>> values ? How the fact >>> that an N50 magnet has a larger remanent field than an N40 one is accounted for >>> in GetDP when >>> Hc(N50) is smaller than Hc(N40) and equal to Hc(N27) ? >>> Thanks a lot for any hints, >>> Gilles >> _______________________________________________ >> getdp mailing list >> [ mailto:getdp at onelab.info | getdp at onelab.info ] >> [ http://onelab.info/mailman/listinfo/getdp | >> http://onelab.info/mailman/listinfo/getdp ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brahim.azzabi-zouraq at etu.univ-nantes.fr Tue Sep 5 10:08:29 2017 From: brahim.azzabi-zouraq at etu.univ-nantes.fr (AZZABI ZOURAQ) Date: Tue, 5 Sep 2017 10:08:29 +0200 Subject: [Getdp] parametric study using GETDP Message-ID: Hi , i'm a PHD student and i am working on an NDT technic based on electrothermal phenomenas. Currently ,I'm using getdp to simulate a nuclear defect case. In order to study the influence of some parameters (such as the defect dimensions ...) i have to implemant a parametric simulation ( solving the problem for each parameter, saving results in a file and doing this for the next parameter value,saving in a different file etc ...). How can i do this in GETDP ? Thanks, Brahim From alexis-hottekilburn at hotmail.com Thu Sep 7 01:59:20 2017 From: alexis-hottekilburn at hotmail.com (Alexis Hotte) Date: Wed, 6 Sep 2017 23:59:20 +0000 Subject: [Getdp] Problem opening non-default waveguide models on onelab mobile app. Message-ID: Hello, I want to start playing with the waveguide models, but the mobile app only includes a few. When I make a folder for the missing one (3D), I of course include the necessary .geo and .pro file, with the infos.xml file that is given on the site?s waveguide.zip. I am trying to open the .zip folder from an email attachment, but when I attempt to do so, I receive this error message: ?Error: Could not create file test/infos.xml?. I am however able to download the demos.boolean.zip folder and open the models from the list. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zip Type: application/octet-stream Size: 33585 bytes Desc: test.zip URL: From cgeuzaine at ulg.ac.be Mon Sep 11 20:34:54 2017 From: cgeuzaine at ulg.ac.be (Christophe Geuzaine) Date: Mon, 11 Sep 2017 20:34:54 +0200 Subject: [Getdp] We will miss him dearly Message-ID: <9EE9F13D-C695-4481-A9C7-5D56053800D5@ulg.ac.be> Dear All, It is with tremendous sadness that I must announce that Patrick Dular, with whom I co-authored GetDP, passed away on September 6th, struck down by a sudden illness at the age of 50. He leaves behind three sons (Julien, Tom and Bruno) and his partner Pascale. Patrick was born on August 28, 1967 in Belgium. After obtaining his PhD thesis in 1994, his whole career blossomed out at the University of Li?ge, appointed by the Belgian Fund for Scientific Research (FNRS) successively as Postdoctoral Researcher in 1994, Research Associate in 1996, Senior Research Associate in 2007, and Research Director (the highest grade at FNRS) in 2012. Patrick?s research was broadly concerned with the mathematical and numerical modelling of electromagnetic systems. In particular, his interests led him to publish seminal papers on the use of Whitney finite elements for three-dimensional eddy current problems, while his recent work focused on advanced techniques to handle the coupling of different physical models and numerical methods. Since 1997, Patrick and I had been developing GetDP for the treatment of such coupled problems. Patrick was an avid traveller and, as a globe-trotter scientist, he was a frequent invited researcher in France, Finland and Brazil, and was part of the scientific committees of numerous international conferences and symposiums. He will be fondly remembered by many current and former students, colleagues and friends for his enthusiasm to communicate about his passion not only for science and engineering, but also for adventure, outdoor activities, photography and of course his three beloved kids. We will miss him dearly. Christophe -- Prof. Christophe Geuzaine University of Liege, Electrical Engineering and Computer Science http://www.montefiore.ulg.ac.be/~geuzaine Free software: http://gmsh.info | http://getdp.info | http://onelab.info From quemener at lpccaen.in2p3.fr Fri Sep 15 15:45:26 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Fri, 15 Sep 2017 15:45:26 +0200 (CEST) Subject: [Getdp] Symmtry problem Message-ID: <1977094400.136778.1505483126523.JavaMail.zimbra@lpccaen.in2p3.fr> Hi, Currently I am trying to formulate and solve a magnetostatic problem using the scalar potential method. This problem is sketched on the attached picture. I have some difficulties finding how to formulate the boundary conditions when simulating only 1/8 of the problem. For the Z = 0 plane it's fine w/ Neumann BC,i.e.t nothing in the formulation. For the Y = 0 plane, I use Dirichlet BC with null scalar potential. My problem is how to express the anti-symmetry : upward field / magnetization in permanent magnets on X>0 and downward direction in the X<0 half space. I have tried to require null scalar potential on plane X=0, but the answer does not look correct. Without any condition on this X=0 plane, I also get incorrect results. Could it be only null scalar potential on the Z-axis ? Then I am a bit confused. Thanks for any help, Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.png Type: image/png Size: 16841 bytes Desc: not available URL: From ferreiro at unse.edu.ar Sat Sep 16 00:19:07 2017 From: ferreiro at unse.edu.ar (Alejandro R. Ferreiro) Date: Fri, 15 Sep 2017 19:19:07 -0300 Subject: [Getdp] We will miss him dearly In-Reply-To: <9EE9F13D-C695-4481-A9C7-5D56053800D5@ulg.ac.be> References: <9EE9F13D-C695-4481-A9C7-5D56053800D5@ulg.ac.be> Message-ID: <9af2908ee74ae0fdf43d584d2e73c956@unse.edu.ar> Dear Christophe, I regret Patrick's sudden departure, being so young. I appreciate the important work done, although it is likely that their projects may be truncated. I value the important task accomplished, although it is probable that their projects will be truncated. Please convey my solidarity to your family. Regards, Alejandro El 2017-09-11 15:34, Christophe Geuzaine escribi?: > Dear All, > > It is with tremendous sadness that I must announce that Patrick Dular, with whom I co-authored GetDP, passed away on September 6th, struck down by a sudden illness at the age of 50. He leaves behind three sons (Julien, Tom and Bruno) and his partner Pascale. > > Patrick was born on August 28, 1967 in Belgium. After obtaining his PhD thesis in 1994, his whole career blossomed out at the University of Li?ge, appointed by the Belgian Fund for Scientific Research (FNRS) successively as Postdoctoral Researcher in 1994, Research Associate in 1996, Senior Research Associate in 2007, and Research Director (the highest grade at FNRS) in 2012. Patrick's research was broadly concerned with the mathematical and numerical modelling of electromagnetic systems. In particular, his interests led him to publish seminal papers on the use of Whitney finite elements for three-dimensional eddy current problems, while his recent work focused on advanced techniques to handle the coupling of different physical models and numerical methods. Since 1997, Patrick and I had been developing GetDP for the treatment of such coupled problems. > > Patrick was an avid traveller and, as a globe-trotter scientist, he was a frequent invited researcher in France, Finland and Brazil, and was part of the scientific committees of numerous international conferences and symposiums. He will be fondly remembered by many current and former students, colleagues and friends for his enthusiasm to communicate about his passion not only for science and engineering, but also for adventure, outdoor activities, photography and of course his three beloved kids. > > We will miss him dearly. > > Christophe -- Mg. Ing. Alejandro R. Ferreiro Director de la Escuela de Ingenier?a Industrial (FCEyT - UNSE) Gral. Savio y La Forja - Parque Industrial (La Banda) Pcia. Santiago del Estero (Argentina) Tel. +54 385 4372354 / Cel. +54 385 5889988 -------------- next part -------------- An HTML attachment was scrubbed... URL: From funkybob at gmail.com Sat Sep 16 22:12:45 2017 From: funkybob at gmail.com (Jasper) Date: Sat, 16 Sep 2017 22:12:45 +0200 Subject: [Getdp] Symmtry problem In-Reply-To: <1977094400.136778.1505483126523.JavaMail.zimbra@lpccaen.in2p3.fr> References: <1977094400.136778.1505483126523.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: Hi Gilles, If I look at your picture, both the XZ and YZ plane should have the "anti-symmetry" boundary condition I think? XY should probably have a symmetry condition. I simulated a similar structure once with a vector potential formulation and used the following boundary conditions on 1/8 of a sphere: SurfAir = Region[ 300 ]; SurfSym = Region[ 310 ]; SurfAsym = Region[ { 320, 321 } ]; Constraint { { Name a; Type Assign; Case { { Region SurfAir; Type Assign ; Value 0.; } { Region SurfSym ; Type Assign ; Value 0. ; } // Symmetry cuts } } } So the "anti-symmetry" does not get any constraints and due to the symmetry constraints it appears a gauge constraint is no longer required. Not sure if this translates to the scalar potential. Best regards, Jasper On Fri, Sep 15, 2017 at 3:45 PM, gilles quemener wrote: > Hi, > > Currently I am trying to formulate and solve a magnetostatic problem using > the scalar potential method. > This problem is sketched on the attached picture. I have some difficulties > finding how to formulate the boundary > conditions when simulating only 1/8 of the problem. > > For the Z = 0 plane it's fine w/ Neumann BC,i.e.t nothing in the > formulation. > For the Y = 0 plane, I use Dirichlet BC with null scalar potential. > My problem is how to express the anti-symmetry : upward field / > magnetization in permanent magnets on X>0 > and downward direction in the X<0 half space. > I have tried to require null scalar potential on plane X=0, but the answer > does not look correct. > Without any condition on this X=0 plane, I also get incorrect results. > Could it be only null scalar potential on the Z-axis ? Then I am a bit > confused. > > Thanks for any help, > > Gilles > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quemener at lpccaen.in2p3.fr Mon Sep 18 08:46:18 2017 From: quemener at lpccaen.in2p3.fr (gilles quemener) Date: Mon, 18 Sep 2017 08:46:18 +0200 (CEST) Subject: [Getdp] Symmtry problem In-Reply-To: References: <1977094400.136778.1505483126523.JavaMail.zimbra@lpccaen.in2p3.fr> Message-ID: <289912190.164651.1505717178424.JavaMail.zimbra@lpccaen.in2p3.fr> Hi Jasper, Thanks for your answer. Indeed we agree on the symmetry ( XY or Z=0 plane) and anti-symmetry planes (XZ or Y=0 plane and YZ or X=0 plane). For the scalar potential approach, the antisymmetry planes XZ and YZ should have 0 scalar potential. I will check again, I have probably done a mistake somewhere. I should try to solve using vector potential as well, but I am less used to it. Best regards, Gilles > De: "Jasper" > ?: "Gilles Qu?m?ner" > Cc: "getdp" > Envoy?: Samedi 16 Septembre 2017 22:12:45 > Objet: Re: [Getdp] Symmtry problem > Hi Gilles, > If I look at your picture, both the XZ and YZ plane should have the > "anti-symmetry" boundary condition I think? > XY should probably have a symmetry condition. > I simulated a similar structure once with a vector potential formulation and > used the following boundary conditions on 1/8 of a sphere: > SurfAir = Region[ 300 ]; > SurfSym = Region[ 310 ]; > SurfAsym = Region[ { 320, 321 } ]; > Constraint { > { Name a; Type Assign; > Case { > { Region SurfAir; Type Assign ; Value 0.; } > { Region SurfSym ; Type Assign ; Value 0. ; } // Symmetry cuts > } > } > } > So the "anti-symmetry" does not get any constraints and due to the symmetry > constraints it appears a gauge constraint is no longer required. > Not sure if this translates to the scalar potential. > Best regards, > Jasper > On Fri, Sep 15, 2017 at 3:45 PM, gilles quemener < [ > mailto:quemener at lpccaen.in2p3.fr | quemener at lpccaen.in2p3.fr ] > wrote: >> Hi, >> Currently I am trying to formulate and solve a magnetostatic problem using the >> scalar potential method. >> This problem is sketched on the attached picture. I have some difficulties >> finding how to formulate the boundary >> conditions when simulating only 1/8 of the problem. >> For the Z = 0 plane it's fine w/ Neumann BC,i.e.t nothing in the formulation. >> For the Y = 0 plane, I use Dirichlet BC with null scalar potential. >> My problem is how to express the anti-symmetry : upward field / magnetization in >> permanent magnets on X>0 >> and downward direction in the X<0 half space. >> I have tried to require null scalar potential on plane X=0, but the answer does >> not look correct. >> Without any condition on this X=0 plane, I also get incorrect results. >> Could it be only null scalar potential on the Z-axis ? Then I am a bit confused. >> Thanks for any help, >> Gilles >> _______________________________________________ >> getdp mailing list >> [ mailto:getdp at onelab.info | getdp at onelab.info ] >> [ http://onelab.info/mailman/listinfo/getdp | >> http://onelab.info/mailman/listinfo/getdp ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From brahim.azzabi-zouraq at etu.univ-nantes.fr Wed Sep 20 10:33:37 2017 From: brahim.azzabi-zouraq at etu.univ-nantes.fr (Brahim AZZABI ZOURAQ) Date: Wed, 20 Sep 2017 10:33:37 +0200 (CEST) Subject: [Getdp] getdp 64bits Message-ID: <3b21d07c9be7f1a3857b65cf02fdcce7.squirrel@webmail-etu.univ-nantes.fr> Hi everybody, I am trying to use getdp on a Windows 7 64 bits PC, i get the following message : incompatible with the windows version used. Is there a 64 bit version of Getdp ? Thanks, Brahim From mai-linh.doan at univ-grenoble-alpes.fr Sun Oct 15 20:18:11 2017 From: mai-linh.doan at univ-grenoble-alpes.fr (Mai-Linh Doan) Date: Sun, 15 Oct 2017 23:48:11 +0530 Subject: [Getdp] Surface integral Message-ID: Hello, Thanks for implementing getdp/gmsh. It?s a very nice software, very well constructed. I?m implementing a model similar to the one described by Evgueni Ianenko in this message : http://onelab.info/pipermail/getdp/2005/000670.html Like Mr Ianenko, I want to complete the total electrical current flowing through a surface. In his reply, Christophe Gueuzaine explained the process to compute the integral of the normal component of the gradient of the electrical potential on a surface : "If you need this component in an integral, the solution in getdp is to use a "OnOneSideOf" group with a BF_GradGroupOfNodes basis function. There is an example here: http://www.geuz.org/getdp/wiki/MagnetoDynamics. You can then use the associated global quantity in post-processing. ? However, the link http://www.geuz.org/getdp/wiki/MagnetoDynamics is not valid anymore. Could you provide a new reference to the demo example ? Thanks a lot ? Mai-Linh PS : I made some research before : - You can find on the OneLab website the description of an electrodynamics problem (http://onelab.info/wiki/Magnetodynamics_with_cohomology_conditions), but it doesn?t use the BF_GradGroupOfNodes basis function. - Searching BF_GradGroupOfNodes, you find another occurence of the same problem (http://onelab.info/pipermail/getdp/2015/001804.html) but the mentioned demo model Capacitor2D is not visible neither on the web! From michael.asam at infineon.com Mon Oct 16 11:35:36 2017 From: michael.asam at infineon.com (michael.asam at infineon.com) Date: Mon, 16 Oct 2017 09:35:36 +0000 Subject: [Getdp] Surface integral In-Reply-To: References: Message-ID: Hello Mai-Linh, unfortunately there is no link on the GetDP webpage to the wiki anymore. You can find the new wiki at https://gitlab.onelab.info/getdp/getdp/wikis/home and the old one ((login: getdp, password: getdp)) at http://onelab.info/trac/getdp/wiki The example you are looking for is in the old wiki. Cheers, Michael -----Original Message----- From: getdp [mailto:getdp-bounces at ace20.montefiore.ulg.ac.be] On Behalf Of Mai-Linh Doan Sent: Sunday, October 15, 2017 8:18 PM To: getdp at onelab.info Subject: [Getdp] Surface integral Hello, Thanks for implementing getdp/gmsh. It?s a very nice software, very well constructed. I?m implementing a model similar to the one described by Evgueni Ianenko in this message : http://onelab.info/pipermail/getdp/2005/000670.html Like Mr Ianenko, I want to complete the total electrical current flowing through a surface. In his reply, Christophe Gueuzaine explained the process to compute the integral of the normal component of the gradient of the electrical potential on a surface : "If you need this component in an integral, the solution in getdp is to use a "OnOneSideOf" group with a BF_GradGroupOfNodes basis function. There is an example here: http://www.geuz.org/getdp/wiki/MagnetoDynamics. You can then use the associated global quantity in post-processing. ? However, the link http://www.geuz.org/getdp/wiki/MagnetoDynamics is not valid anymore. Could you provide a new reference to the demo example ? Thanks a lot ? Mai-Linh PS : I made some research before : - You can find on the OneLab website the description of an electrodynamics problem (http://onelab.info/wiki/Magnetodynamics_with_cohomology_conditions), but it doesn?t use the BF_GradGroupOfNodes basis function. - Searching BF_GradGroupOfNodes, you find another occurence of the same problem (http://onelab.info/pipermail/getdp/2015/001804.html) but the mentioned demo model Capacitor2D is not visible neither on the web! _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp From ajpina at gmail.com Tue Oct 17 03:26:56 2017 From: ajpina at gmail.com (Alejandro Pina) Date: Mon, 16 Oct 2017 21:26:56 -0400 Subject: [Getdp] Error : GetDP - '/.../Motor0.geo', line 30 : syntax error (() Message-ID: Hi List, Hope you can help me with the following issue: I have a motor geometry 'Motor0.geo' that is apparently meshed with Gmsh without any issues, however when I open ?Motor0.pro?, it triggers an error during GetDP check. The error is shown below, Info : ------------------------------------------------------- Info : Gmsh version : 3.0.5 Info : Build OS : MacOSX Info : Build options : Ann Bamg Bfgs Blas(Custom) Blossom C++11 Chaco DIntegration Dlopen Fltk Gmm Jpeg(Fltk) Kbipack Lapack(Custom) MathEx Med Mesh Metis Mmg3d Mpeg NativeFileChooser Netgen ONELAB ONELABMetamodel OpenCASCADE OpenGL OptHom PETSc Parser Plugins Png(Fltk) Post SLEPc Solver Taucs TetGen/BR Tetgen1.5 Voro3D Zlib Info : Build date : 20170906 Info : Build host : Admins-Mac.local Info : Packager : geuzaine Info : Executable : /Applications/Gmsh.app/Contents/MacOS/gmsh Info : Home directory : /Users/ajpina/ Info : Launch date : Mon Oct 16 21:04:44 2017 Info : Command line : /Applications/Gmsh.app/Contents/MacOS/gmsh Info : ------------------------------------------------------- Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.pro'... Info : Calling '"/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp" -onelab "GetDP" /Users/ajpina/.gmshsock2 &' Info : Running 'GetDP'? Info : GetDP - Performing ONELAB 'initialize' Info : Done running 'GetDP' Info : Done Info : Resetting database Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo'... Info : Done reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo' Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo.opt'... Info : Done reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo.opt' Info : Calling '"/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp" "/Volumes/Share/Linux/gmsh-files/Motor0.pro" -onelab "GetDP" /Users/ajpina/.gmshsock2 &' Info : Running 'GetDP'... Info : GetDP - Performing ONELAB 'check' Info : GetDP - Running '/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp /Volumes/Share/Linux/gmsh-files/Motor0.pro -onelab GetDP /Users/ajpina/.gmshsock2' [GetDP 2.11.2, 1 node] Info : GetDP - Started (Mon Oct 16 21:04:44 2017, Wall = 0.0333641s, CPU = 0.03193s, Mem = 6.71094Mb, Recv/Send = 6.67572e-05/0.000526428Mb) Info : GetDP - Got mesh name from Onelab: '/Volumes/Share/Linux/gmsh-files/Motor0.msh' Info : GetDP - Initializing Gmsh Info : GetDP - Loading problem definition '/Volumes/Share/Linux/gmsh-files/Motor0.pro' Info : GetDP - Loading problem definition '/Volumes/Share/Linux/gmsh-files/Motor0.geo' Error : GetDP - '/Volumes/Share/Linux/gmsh-files/Motor0.geo', line 30 : syntax error (() Info : Done running 'GetDP' Info : Done The line 30 in file ?Motor0.geo? is the following (by the way, all parameters have been previously initialized): M_aai = ( 2/beta )*Asin( M_w / ( 2*oRr ) ) ; I wonder why no error is shown when open 'Motor0.geo? instead of ?Motor0.pro?. Hope you can give a clue, also I can send more information on what the files have in them if required. Thanks, Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.henrotte at uclouvain.be Tue Oct 17 07:45:12 2017 From: francois.henrotte at uclouvain.be (=?Windows-1252?Q?Fran=E7ois_Henrotte?=) Date: Tue, 17 Oct 2017 05:45:12 +0000 Subject: [Getdp] Error : GetDP - '/.../Motor0.geo', line 30 : syntax error (() In-Reply-To: References: Message-ID: Le 17 oct. 2017 ? 03:26, Alejandro Pina > a ?crit : Hi List, Hope you can help me with the following issue: I have a motor geometry 'Motor0.geo' that is apparently meshed with Gmsh without any issues, however when I open ?Motor0.pro?, it triggers an error during GetDP check. The error is shown below, Info : ------------------------------------------------------- Info : Gmsh version : 3.0.5 Info : Build OS : MacOSX Info : Build options : Ann Bamg Bfgs Blas(Custom) Blossom C++11 Chaco DIntegration Dlopen Fltk Gmm Jpeg(Fltk) Kbipack Lapack(Custom) MathEx Med Mesh Metis Mmg3d Mpeg NativeFileChooser Netgen ONELAB ONELABMetamodel OpenCASCADE OpenGL OptHom PETSc Parser Plugins Png(Fltk) Post SLEPc Solver Taucs TetGen/BR Tetgen1.5 Voro3D Zlib Info : Build date : 20170906 Info : Build host : Admins-Mac.local Info : Packager : geuzaine Info : Executable : /Applications/Gmsh.app/Contents/MacOS/gmsh Info : Home directory : /Users/ajpina/ Info : Launch date : Mon Oct 16 21:04:44 2017 Info : Command line : /Applications/Gmsh.app/Contents/MacOS/gmsh Info : ------------------------------------------------------- Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.pro'... Info : Calling '"/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp" -onelab "GetDP" /Users/ajpina/.gmshsock2 &' Info : Running 'GetDP'? Info : GetDP - Performing ONELAB 'initialize' Info : Done running 'GetDP' Info : Done Info : Resetting database Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo'... Info : Done reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo' Info : Reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo.opt'... Info : Done reading '/Volumes/Share/Linux/gmsh-files/Motor0.geo.opt' Info : Calling '"/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp" "/Volumes/Share/Linux/gmsh-files/Motor0.pro" -onelab "GetDP" /Users/ajpina/.gmshsock2 &' Info : Running 'GetDP'... Info : GetDP - Performing ONELAB 'check' Info : GetDP - Running '/Volumes/Share/Linux/getdp-2.11.2-MacOSX/bin/getdp /Volumes/Share/Linux/gmsh-files/Motor0.pro -onelab GetDP /Users/ajpina/.gmshsock2' [GetDP 2.11.2, 1 node] Info : GetDP - Started (Mon Oct 16 21:04:44 2017, Wall = 0.0333641s, CPU = 0.03193s, Mem = 6.71094Mb, Recv/Send = 6.67572e-05/0.000526428Mb) Info : GetDP - Got mesh name from Onelab: '/Volumes/Share/Linux/gmsh-files/Motor0.msh' Info : GetDP - Initializing Gmsh Info : GetDP - Loading problem definition '/Volumes/Share/Linux/gmsh-files/Motor0.pro' Info : GetDP - Loading problem definition '/Volumes/Share/Linux/gmsh-files/Motor0.geo' Error : GetDP - '/Volumes/Share/Linux/gmsh-files/Motor0.geo', line 30 : syntax error (() Info : Done running 'GetDP' Info : Done The line 30 in file ?Motor0.geo? is the following (by the way, all parameters have been previously initialized): M_aai = ( 2/beta )*Asin( M_w / ( 2*oRr ) ) ; From http://getdp.info/doc/texinfo/getdp.html one sees that the correct syntax for functions is with square brackets Asin [expression] Arc sine (inverse sine) of expression in [-Pi/2,Pi/2], expression in [-1,1] (real valued only). So, M_aai = ( 2/beta )*Asin[ M_w / ( 2*oRr ) ] ; Regards, Fr. I wonder why no error is shown when open 'Motor0.geo? instead of ?Motor0.pro?. Hope you can give a clue, also I can send more information on what the files have in them if required. Thanks, Alejandro _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -- Fran?ois Henrotte Dr Ir - francois.henrotte at uclouvain.be - francois.henrotte at ulg.ac.be UCL - B?t. Euler a.217 - Av. G. Lema?tre 4-6 , B-1348 Louvain-la-Neuve - +32(0)10 47 23 64 ULg - Institut Montefiore I154 - All?e de la D?couverte 10, B-4000 Li?ge - +32(0)4 366 37 36 -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Tue Oct 17 11:04:07 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Tue, 17 Oct 2017 18:04:07 +0900 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) Message-ID: Dear All, I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. They are: Formulation { { Name MagStaDyn_av_js0_3D ; Type FemEquation ; Quantity { { Name a ; Type Local ; NameOfSpace HSpace ; } { Name v ; Type Local ; NameOfSpace USpace ; } } Equation { Galerkin { [ nu[] * Dof{d a} , {d a} ] ; In Domain ; Jacobian Vol ; Integration II ; } Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ sigma[] * Dof{d v} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ -js0[], {a} ] ; In DomainS ; Jacobian Vol ; Integration II ; } Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } } } { Name Thermal; Type FemEquation; Quantity { { Name t; Type Local; NameOfSpace TSpace; } { Name a; Type Local; NameOfSpace HSpace; } { Name v; Type Local; NameOfSpace USpace; } } Equation { Galerkin { [ K[] * Dof{d t}, {d t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ -1./sigma[]*( Re[-(Dt[{a}]+{d v})]* Re[-(Dt[{a}]+{d v})]+ Im[-(Dt[{a}]+{d v})]* Im[-(Dt[{a}]+{d v})]), {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ Ht[]*Dof{t}, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [-Ht[]*Tamb[], {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } } } } The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? Any ways for A-V formulation? Thank you so much. Best, ABE Hiroshi from Tokorozawa, JAPAN From ruth.sabariego at kuleuven.be Tue Oct 17 17:04:21 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Tue, 17 Oct 2017 15:04:21 +0000 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) In-Reply-To: References: Message-ID: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> Dear ABE Hiroshi, Using the T-O or the A-V formulation is just a choice, that most of the time depends on the data we have. Refining the mesh, you should observe convergence of the results. As you?ve done, the coupling between the EM and the thermal problem is done via the Joule losses. These losses are calculated from the frequency domain solution (steady state) of the AV-formulation, and therefore they are an average value. The thermal problem is then solve in the time domain. This is possible thanks to the difference in time constants of both problems. The coupling term can be written as: Galerkin { [ -0.5*sigma[] *[ SquNorm[Dt[{a}]+{d v}] ], {t} ]; In DomainC; Integration II; Jacobian Vol; } where indicates that the operation between square brackets is to be done with complex numbers even if the thermal formulation is real. This term is exactly the same as yours (with a factor 0.5, that I think is missing, to check!) if you also indicate there that the quantities are complex, i.e. Galerkin { [ -1./sigma[]*( [ Re[-(Dt[{a}]+{d v})]* Re[-(Dt[{a}]+{d v})]+ Im[-(Dt[{a}]+{d v})]* Im[-(Dt[{a}]+{d v})]] ), {t} ]; In DomainC; Integration II; Jacobian Vol; } If you do not indicate that the quantities are complex, the imaginary part is disregarded in the time domain thermal formulation. Regards, Ruth PS: I am correcting the formulation in the benchmarks. ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 17 Oct 2017, at 11:04, ABE Hiroshi > wrote: Dear All, I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. They are: Formulation { { Name MagStaDyn_av_js0_3D ; Type FemEquation ; Quantity { { Name a ; Type Local ; NameOfSpace HSpace ; } { Name v ; Type Local ; NameOfSpace USpace ; } } Equation { Galerkin { [ nu[] * Dof{d a} , {d a} ] ; In Domain ; Jacobian Vol ; Integration II ; } Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ sigma[] * Dof{d v} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ -js0[], {a} ] ; In DomainS ; Jacobian Vol ; Integration II ; } Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } } } { Name Thermal; Type FemEquation; Quantity { { Name t; Type Local; NameOfSpace TSpace; } { Name a; Type Local; NameOfSpace HSpace; } { Name v; Type Local; NameOfSpace USpace; } } Equation { Galerkin { [ K[] * Dof{d t}, {d t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ -1./sigma[]*( Re[-(Dt[{a}]+{d v})]* Re[-(Dt[{a}]+{d v})]+ Im[-(Dt[{a}]+{d v})]* Im[-(Dt[{a}]+{d v})]), {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ Ht[]*Dof{t}, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [-Ht[]*Tamb[], {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } } } } The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? Any ways for A-V formulation? Thank you so much. Best, ABE Hiroshi from Tokorozawa, JAPAN _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Wed Oct 18 06:47:16 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Wed, 18 Oct 2017 13:47:16 +0900 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) In-Reply-To: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> References: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> Message-ID: Dear Prof Sabariego, Thank you for your very helpful information, function. Also I got the situation on the detail of the formulation. I?ll try further on my application. Best, 2017/10/18 0:04?Ruth Vazquez Sabariego ????? > Dear ABE Hiroshi, > > Using the T-O or the A-V formulation is just a choice, that most of the time depends on the data we have. > Refining the mesh, you should observe convergence of the results. > > As you?ve done, the coupling between the EM and the thermal problem is done via the Joule losses. > These losses are calculated from the frequency domain solution (steady state) of the AV-formulation, and therefore they are an average value. > The thermal problem is then solve in the time domain. This is possible thanks to the difference in time constants of both problems. > > The coupling term can be written as: > > Galerkin { [ -0.5*sigma[] *[ SquNorm[Dt[{a}]+{d v}] ], {t} ]; > In DomainC; Integration II; Jacobian Vol; } > > where indicates that the operation between square brackets is to be done with complex numbers even if the thermal formulation is real. > > This term is exactly the same as yours (with a factor 0.5, that I think is missing, to check!) if you also indicate there that the quantities are complex, i.e. >> Galerkin { [ -1./sigma[]*( [ >> Re[-(Dt[{a}]+{d v})]* >> Re[-(Dt[{a}]+{d v})]+ >> Im[-(Dt[{a}]+{d v})]* >> Im[-(Dt[{a}]+{d v})]] ), {t} ]; >> In DomainC; Integration II; Jacobian Vol; } > > > If you do not indicate that the quantities are complex, the imaginary part is disregarded in the time domain thermal formulation. > > Regards, > Ruth > > PS: I am correcting the formulation in the benchmarks. > > >> On 17 Oct 2017, at 11:04, ABE Hiroshi wrote: >> >> Dear All, >> >> I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. >> It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. >> >> They are: >> >> Formulation { >> >> { Name MagStaDyn_av_js0_3D ; Type FemEquation ; >> Quantity { >> { Name a ; Type Local ; NameOfSpace HSpace ; } >> { Name v ; Type Local ; NameOfSpace USpace ; } >> } >> >> Equation { >> Galerkin { [ nu[] * Dof{d a} , {d a} ] ; >> In Domain ; Jacobian Vol ; Integration II ; } >> Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> Galerkin { [ sigma[] * Dof{d v} , {a} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> >> Galerkin { [ -js0[], {a} ] ; >> In DomainS ; Jacobian Vol ; Integration II ; } >> >> >> Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> >> } >> } >> >> { Name Thermal; Type FemEquation; >> Quantity { >> { Name t; Type Local; NameOfSpace TSpace; } >> { Name a; Type Local; NameOfSpace HSpace; } >> { Name v; Type Local; NameOfSpace USpace; } >> } >> Equation { >> Galerkin { [ K[] * Dof{d t}, {d t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> Galerkin { [ -1./sigma[]*( >> Re[-(Dt[{a}]+{d v})]* >> Re[-(Dt[{a}]+{d v})]+ >> Im[-(Dt[{a}]+{d v})]* >> Im[-(Dt[{a}]+{d v})]), {t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> >> Galerkin { [ Ht[]*Dof{t}, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [-Ht[]*Tamb[], {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> >> } >> } >> } >> >> The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. >> >> I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? >> Any ways for A-V formulation? >> >> Thank you so much. >> ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Wed Oct 18 16:14:06 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Wed, 18 Oct 2017 23:14:06 +0900 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) In-Reply-To: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> References: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> Message-ID: <97B7AC3B-B127-4DD2-9936-184D07AAB863@gmail.com> Dear Prof. Sabariego and All, I looked into the new indheat.pro benchmark and change several lines to use AV formulation, MagDynAV formulation. The diff file is this. 325c325,326 < { Name h; Type Local; NameOfSpace HSpace; } --- > { Name a; Type Local; NameOfSpace ASpace; } > { Name e; Type Local; NameOfSpace ESpace; } 333c334 < Galerkin { [ -0.5/sigma[]*[Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}]], {t} ]; --- > Galerkin { [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]], {t} ]; 378c379 < { Name A; NameOfFormulation MagDynTO; --- > { Name A; NameOfFormulation MagDynAV; 478c479 < { Name p; Value{ Local{ [ 1./sigma[]*( Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}] ) ] ; --- > { Name p; Value{ Local{ [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]] ] ; The simulation results are very different from the original TO formulation. My concerning points are * In AV formulation, ?a" and ?e" are both complex numbers so [] should be something like []. * The operator ?Dt? would work as expected in the TheDyn formulation, it is transient formulation. I tried [], but this causes a syntax error. I have a feeling I am closing to my goal. I appreciate your kind helps. Thank you very much in advance. Best Regards, 2017/10/18 0:04?Ruth Vazquez Sabariego ????? > Dear ABE Hiroshi, > > Using the T-O or the A-V formulation is just a choice, that most of the time depends on the data we have. > Refining the mesh, you should observe convergence of the results. > > As you?ve done, the coupling between the EM and the thermal problem is done via the Joule losses. > These losses are calculated from the frequency domain solution (steady state) of the AV-formulation, and therefore they are an average value. > The thermal problem is then solve in the time domain. This is possible thanks to the difference in time constants of both problems. > > The coupling term can be written as: > > Galerkin { [ -0.5*sigma[] *[ SquNorm[Dt[{a}]+{d v}] ], {t} ]; > In DomainC; Integration II; Jacobian Vol; } > > where indicates that the operation between square brackets is to be done with complex numbers even if the thermal formulation is real. > > This term is exactly the same as yours (with a factor 0.5, that I think is missing, to check!) if you also indicate there that the quantities are complex, i.e. >> Galerkin { [ -1./sigma[]*( [ >> Re[-(Dt[{a}]+{d v})]* >> Re[-(Dt[{a}]+{d v})]+ >> Im[-(Dt[{a}]+{d v})]* >> Im[-(Dt[{a}]+{d v})]] ), {t} ]; >> In DomainC; Integration II; Jacobian Vol; } > > > If you do not indicate that the quantities are complex, the imaginary part is disregarded in the time domain thermal formulation. > > Regards, > Ruth > > PS: I am correcting the formulation in the benchmarks. > > > ? > Prof. Ruth V. Sabariego > KU Leuven > Dept. Electrical Engineering ESAT/Electa, EnergyVille > http://www.esat.kuleuven.be/electa > http://www.energyville.be > > Free software: http://gmsh.info | http://getdp.info | http://onelab.info > > > > > > > >> On 17 Oct 2017, at 11:04, ABE Hiroshi wrote: >> >> Dear All, >> >> I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. >> It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. >> >> They are: >> >> Formulation { >> >> { Name MagStaDyn_av_js0_3D ; Type FemEquation ; >> Quantity { >> { Name a ; Type Local ; NameOfSpace HSpace ; } >> { Name v ; Type Local ; NameOfSpace USpace ; } >> } >> >> Equation { >> Galerkin { [ nu[] * Dof{d a} , {d a} ] ; >> In Domain ; Jacobian Vol ; Integration II ; } >> Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> Galerkin { [ sigma[] * Dof{d v} , {a} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> >> Galerkin { [ -js0[], {a} ] ; >> In DomainS ; Jacobian Vol ; Integration II ; } >> >> >> Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; >> In DomainC ; Jacobian Vol ; Integration II ; } >> >> } >> } >> >> { Name Thermal; Type FemEquation; >> Quantity { >> { Name t; Type Local; NameOfSpace TSpace; } >> { Name a; Type Local; NameOfSpace HSpace; } >> { Name v; Type Local; NameOfSpace USpace; } >> } >> Equation { >> Galerkin { [ K[] * Dof{d t}, {d t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> Galerkin { [ -1./sigma[]*( >> Re[-(Dt[{a}]+{d v})]* >> Re[-(Dt[{a}]+{d v})]+ >> Im[-(Dt[{a}]+{d v})]* >> Im[-(Dt[{a}]+{d v})]), {t} ]; >> In DomainC; Integration II; Jacobian Vol; } >> >> Galerkin { [ Ht[]*Dof{t}, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [-Ht[]*Tamb[], {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; >> In Skin_ECore; Jacobian Sur ; Integration II ; } >> >> } >> } >> } >> >> The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. >> >> I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? >> Any ways for A-V formulation? >> >> Thank you so much. >> >> Best, >> >> ABE Hiroshi >> from Tokorozawa, JAPAN >> >> >> _______________________________________________ >> getdp mailing list >> getdp at onelab.info >> http://onelab.info/mailman/listinfo/getdp > ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruth.sabariego at kuleuven.be Wed Oct 18 21:10:33 2017 From: ruth.sabariego at kuleuven.be (Ruth Vazquez Sabariego) Date: Wed, 18 Oct 2017 19:10:33 +0000 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) In-Reply-To: <97B7AC3B-B127-4DD2-9936-184D07AAB863@gmail.com> References: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> <97B7AC3B-B127-4DD2-9936-184D07AAB863@gmail.com> Message-ID: <4B0265EF-9753-409C-9B62-DF33FEEB1307@kuleuven.be> Dear ABE Hiroshi, In the term you have written: Galerkin { [ -0.5/sigma[]*[ Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]], {t} ]; I think you have a sign error as: j= -sigma*(Dt[a]+{e}) With regard to your questions: 1) it is not necessary to indicate the two quantities in between <>, it will work with complex arithmetic in what follows between []. 2) in complex arithmetic, Dt[] implies => 1i*2*pi*freq*{a}; and that?s what should be used. The correct term should be: Galerkin { [ -0.5*sigma[]* [ Re[Dt[{a}]+{e}] ]*Re[Dt[{a}]+{e}] ]+Im[Dt[{a}]+{e}] ]*Im[Dt[{a}]+{e}] ] , {t} ]; In Omega_c2; Integration Int; Jacobian Vol; } or in a more compact form: Galerkin { [ -0.5*sigma[]* [ SquNorm[Dt[{a}]+{e}] ], {t} ]; In Omega_c2; Integration Int; Jacobian Vol; } Best regards, Ruth ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 18 Oct 2017, at 16:14, ABE Hiroshi > wrote: Dear Prof. Sabariego and All, I looked into the new indheat.pro benchmark and change several lines to use AV formulation, MagDynAV formulation. The diff file is this. 325c325,326 < { Name h; Type Local; NameOfSpace HSpace; } --- > { Name a; Type Local; NameOfSpace ASpace; } > { Name e; Type Local; NameOfSpace ESpace; } 333c334 < Galerkin { [ -0.5/sigma[]*[Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}]], {t} ]; --- > Galerkin { [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]], {t} ]; 378c379 < { Name A; NameOfFormulation MagDynTO; --- > { Name A; NameOfFormulation MagDynAV; 478c479 < { Name p; Value{ Local{ [ 1./sigma[]*( Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}] ) ] ; --- > { Name p; Value{ Local{ [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]] ] ; The simulation results are very different from the original TO formulation. My concerning points are * In AV formulation, ?a" and ?e" are both complex numbers so [] should be something like []. * The operator ?Dt? would work as expected in the TheDyn formulation, it is transient formulation. I tried [], but this causes a syntax error. I have a feeling I am closing to my goal. I appreciate your kind helps. Thank you very much in advance. Best Regards, 2017/10/18 0:04?Ruth Vazquez Sabariego > ????? Dear ABE Hiroshi, Using the T-O or the A-V formulation is just a choice, that most of the time depends on the data we have. Refining the mesh, you should observe convergence of the results. As you?ve done, the coupling between the EM and the thermal problem is done via the Joule losses. These losses are calculated from the frequency domain solution (steady state) of the AV-formulation, and therefore they are an average value. The thermal problem is then solve in the time domain. This is possible thanks to the difference in time constants of both problems. The coupling term can be written as: Galerkin { [ -0.5*sigma[] *[ SquNorm[Dt[{a}]+{d v}] ], {t} ]; In DomainC; Integration II; Jacobian Vol; } where indicates that the operation between square brackets is to be done with complex numbers even if the thermal formulation is real. This term is exactly the same as yours (with a factor 0.5, that I think is missing, to check!) if you also indicate there that the quantities are complex, i.e. Galerkin { [ -1./sigma[]*( [ Re[-(Dt[{a}]+{d v})]* Re[-(Dt[{a}]+{d v})]+ Im[-(Dt[{a}]+{d v})]* Im[-(Dt[{a}]+{d v})]] ), {t} ]; In DomainC; Integration II; Jacobian Vol; } If you do not indicate that the quantities are complex, the imaginary part is disregarded in the time domain thermal formulation. Regards, Ruth PS: I am correcting the formulation in the benchmarks. ? Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa http://www.energyville.be Free software: http://gmsh.info | http://getdp.info | http://onelab.info On 17 Oct 2017, at 11:04, ABE Hiroshi > wrote: Dear All, I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. They are: Formulation { { Name MagStaDyn_av_js0_3D ; Type FemEquation ; Quantity { { Name a ; Type Local ; NameOfSpace HSpace ; } { Name v ; Type Local ; NameOfSpace USpace ; } } Equation { Galerkin { [ nu[] * Dof{d a} , {d a} ] ; In Domain ; Jacobian Vol ; Integration II ; } Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ sigma[] * Dof{d v} , {a} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin { [ -js0[], {a} ] ; In DomainS ; Jacobian Vol ; Integration II ; } Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; In DomainC ; Jacobian Vol ; Integration II ; } } } { Name Thermal; Type FemEquation; Quantity { { Name t; Type Local; NameOfSpace TSpace; } { Name a; Type Local; NameOfSpace HSpace; } { Name v; Type Local; NameOfSpace USpace; } } Equation { Galerkin { [ K[] * Dof{d t}, {d t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ -1./sigma[]*( Re[-(Dt[{a}]+{d v})]* Re[-(Dt[{a}]+{d v})]+ Im[-(Dt[{a}]+{d v})]* Im[-(Dt[{a}]+{d v})]), {t} ]; In DomainC; Integration II; Jacobian Vol; } Galerkin { [ Ht[]*Dof{t}, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [-Ht[]*Tamb[], {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; In Skin_ECore; Jacobian Sur ; Integration II ; } } } } The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? Any ways for A-V formulation? Thank you so much. Best, ABE Hiroshi from Tokorozawa, JAPAN _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp ABE Hiroshi from Tokorozawa, JAPAN _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Thu Oct 19 02:55:05 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Thu, 19 Oct 2017 09:55:05 +0900 Subject: [Getdp] Coupling Analysis (Thermo MagDyn) In-Reply-To: <4B0265EF-9753-409C-9B62-DF33FEEB1307@kuleuven.be> References: <3E1EE7D1-A5A4-4E15-AE76-BD5D6A1CC853@kuleuven.be> <97B7AC3B-B127-4DD2-9936-184D07AAB863@gmail.com> <4B0265EF-9753-409C-9B62-DF33FEEB1307@kuleuven.be> Message-ID: <3D3B6CA8-87E4-45E9-B0BC-C15EA43834DC@gmail.com> Dear Prof. Sabariego and All, Thank you and I apology my mistake that should be avoided. I changed the mistake and have confirmed. As the pictures attatched in this mail, the results are almost same. Thank you so much. The diff file to the original indheat.pro is: 325c325,326 < { Name h; Type Local; NameOfSpace HSpace; } --- > { Name a; Type Local; NameOfSpace ASpace; } > { Name e; Type Local; NameOfSpace ESpace; } 333c334 < Galerkin { [ -0.5/sigma[]*[Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}]], {t} ]; --- > Galerkin { [ -0.5*sigma[]*[ SquNorm[Dt[{a}]+{e}]], {t} ]; 378c379 < { Name A; NameOfFormulation MagDynTO; --- > { Name A; NameOfFormulation MagDynAV; 478,479c479,480 < { Name p; Value{ Local{ [ 1./sigma[]*( Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}] ) ] ; < In Omega_c2; Jacobian Vol; } } } --- > { Name p; Value{ Local{ [ sigma[]*[ SquNorm[(Dt[{a}]+{e})] ] ] ; > In Omega_c2; Jacobian Vol; } } } Best Regards, 2017/10/19 4:10?Ruth Vazquez Sabariego ????? > Dear ABE Hiroshi, > > In the term you have written: >> Galerkin { [ -0.5/sigma[]*[ Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]], {t} ]; > > > I think you have a sign error as: > j= -sigma*(Dt[a]+{e}) > > With regard to your questions: > 1) it is not necessary to indicate the two quantities in between <>, it will work with complex arithmetic in what follows between []. > 2) in complex arithmetic, Dt[] implies => 1i*2*pi*freq*{a}; and that?s what should be used. > > The correct term should be: > > Galerkin { [ -0.5*sigma[]* [ Re[Dt[{a}]+{e}] ]*Re[Dt[{a}]+{e}] ]+Im[Dt[{a}]+{e}] ]*Im[Dt[{a}]+{e}] ] , {t} ]; > In Omega_c2; Integration Int; Jacobian Vol; } > > or in a more compact form: > Galerkin { [ -0.5*sigma[]* [ SquNorm[Dt[{a}]+{e}] ], {t} ]; > In Omega_c2; Integration Int; Jacobian Vol; } > > Best regards, > Ruth > > > ? > Prof. Ruth V. Sabariego > KU Leuven > Dept. Electrical Engineering ESAT/Electa, EnergyVille > http://www.esat.kuleuven.be/electa > http://www.energyville.be > > Free software: http://gmsh.info | http://getdp.info | http://onelab.info > > > > > > > >> On 18 Oct 2017, at 16:14, ABE Hiroshi wrote: >> >> Dear Prof. Sabariego and All, >> >> I looked into the new indheat.pro benchmark and change several lines to use AV formulation, MagDynAV formulation. >> >> The diff file is this. >> >> 325c325,326 >> < { Name h; Type Local; NameOfSpace HSpace; } >> --- >> > { Name a; Type Local; NameOfSpace ASpace; } >> > { Name e; Type Local; NameOfSpace ESpace; } >> 333c334 >> < Galerkin { [ -0.5/sigma[]*[Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}]], {t} ]; >> --- >> > Galerkin { [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]], {t} ]; >> 378c379 >> < { Name A; NameOfFormulation MagDynTO; >> --- >> > { Name A; NameOfFormulation MagDynAV; >> 478c479 >> < { Name p; Value{ Local{ [ 1./sigma[]*( Re[{d h}]*Re[{d h}] + Im[{d h}]*Im[{d h}] ) ] ; >> --- >> > { Name p; Value{ Local{ [ -0.5/sigma[]*[Re[Dt[-{a}]+{e}]*Re[Dt[-{a}]+{e}] + Im[Dt[-{a}]+{e}]*Im[Dt[-{a}]+{e}]] ] ; >> >> The simulation results are very different from the original TO formulation. >> My concerning points are >> * In AV formulation, ?a" and ?e" are both complex numbers so [] should be something like []. >> * The operator ?Dt? would work as expected in the TheDyn formulation, it is transient formulation. >> >> I tried [], but this causes a syntax error. >> I have a feeling I am closing to my goal. I appreciate your kind helps. >> Thank you very much in advance. >> >> Best Regards, >> >> >> 2017/10/18 0:04?Ruth Vazquez Sabariego ????? >> >>> Dear ABE Hiroshi, >>> >>> Using the T-O or the A-V formulation is just a choice, that most of the time depends on the data we have. >>> Refining the mesh, you should observe convergence of the results. >>> >>> As you?ve done, the coupling between the EM and the thermal problem is done via the Joule losses. >>> These losses are calculated from the frequency domain solution (steady state) of the AV-formulation, and therefore they are an average value. >>> The thermal problem is then solve in the time domain. This is possible thanks to the difference in time constants of both problems. >>> >>> The coupling term can be written as: >>> >>> Galerkin { [ -0.5*sigma[] *[ SquNorm[Dt[{a}]+{d v}] ], {t} ]; >>> In DomainC; Integration II; Jacobian Vol; } >>> >>> where indicates that the operation between square brackets is to be done with complex numbers even if the thermal formulation is real. >>> >>> This term is exactly the same as yours (with a factor 0.5, that I think is missing, to check!) if you also indicate there that the quantities are complex, i.e. >>>> Galerkin { [ -1./sigma[]*( [ >>>> Re[-(Dt[{a}]+{d v})]* >>>> Re[-(Dt[{a}]+{d v})]+ >>>> Im[-(Dt[{a}]+{d v})]* >>>> Im[-(Dt[{a}]+{d v})]] ), {t} ]; >>>> In DomainC; Integration II; Jacobian Vol; } >>> >>> >>> If you do not indicate that the quantities are complex, the imaginary part is disregarded in the time domain thermal formulation. >>> >>> Regards, >>> Ruth >>> >>> PS: I am correcting the formulation in the benchmarks. >>> >>> >>> ? >>> Prof. Ruth V. Sabariego >>> KU Leuven >>> Dept. Electrical Engineering ESAT/Electa, EnergyVille >>> http://www.esat.kuleuven.be/electa >>> http://www.energyville.be >>> >>> Free software: http://gmsh.info | http://getdp.info | http://onelab.info >>> >>> >>> >>> >>> >>> >>> >>>> On 17 Oct 2017, at 11:04, ABE Hiroshi wrote: >>>> >>>> Dear All, >>>> >>>> I am working on a coupling analysis of magnetodynamics and thermal dynamics. Referring to ?indheat? sample, I build a model. >>>> It uses A-V formulation regarding Magnetodynamics, and I would like to couple the electric current in the thermal formulation. >>>> >>>> They are: >>>> >>>> Formulation { >>>> >>>> { Name MagStaDyn_av_js0_3D ; Type FemEquation ; >>>> Quantity { >>>> { Name a ; Type Local ; NameOfSpace HSpace ; } >>>> { Name v ; Type Local ; NameOfSpace USpace ; } >>>> } >>>> >>>> Equation { >>>> Galerkin { [ nu[] * Dof{d a} , {d a} ] ; >>>> In Domain ; Jacobian Vol ; Integration II ; } >>>> Galerkin { DtDof[ sigma[] * Dof{a} , {a} ] ; >>>> In DomainC ; Jacobian Vol ; Integration II ; } >>>> Galerkin { [ sigma[] * Dof{d v} , {a} ] ; >>>> In DomainC ; Jacobian Vol ; Integration II ; } >>>> >>>> Galerkin { [ -js0[], {a} ] ; >>>> In DomainS ; Jacobian Vol ; Integration II ; } >>>> >>>> >>>> Galerkin{ DtDof[ sigma[] * Dof{a}, {d v} ] ; >>>> In DomainC ; Jacobian Vol ; Integration II ; } >>>> Galerkin{ [ sigma[] * Dof{d v} , {d v} ] ; >>>> In DomainC ; Jacobian Vol ; Integration II ; } >>>> >>>> } >>>> } >>>> >>>> { Name Thermal; Type FemEquation; >>>> Quantity { >>>> { Name t; Type Local; NameOfSpace TSpace; } >>>> { Name a; Type Local; NameOfSpace HSpace; } >>>> { Name v; Type Local; NameOfSpace USpace; } >>>> } >>>> Equation { >>>> Galerkin { [ K[] * Dof{d t}, {d t} ]; >>>> In DomainC; Integration II; Jacobian Vol; } >>>> Galerkin { DtDof [ rho[]*Cp[] * Dof{t}, {t} ]; >>>> In DomainC; Integration II; Jacobian Vol; } >>>> Galerkin { [ -1./sigma[]*( >>>> Re[-(Dt[{a}]+{d v})]* >>>> Re[-(Dt[{a}]+{d v})]+ >>>> Im[-(Dt[{a}]+{d v})]* >>>> Im[-(Dt[{a}]+{d v})]), {t} ]; >>>> In DomainC; Integration II; Jacobian Vol; } >>>> >>>> Galerkin { [ Ht[]*Dof{t}, {t} ]; >>>> In Skin_ECore; Jacobian Sur ; Integration II ; } >>>> Galerkin { [-Ht[]*Tamb[], {t} ]; >>>> In Skin_ECore; Jacobian Sur ; Integration II ; } >>>> Galerkin { [ sigma_sb*Ep[]*(Dof{t})^4, {t} ]; >>>> In Skin_ECore; Jacobian Sur ; Integration II ; } >>>> Galerkin { [ -sigma_sb*Ep[]*(Tamb[])^4, {t} ]; >>>> In Skin_ECore; Jacobian Sur ; Integration II ; } >>>> >>>> } >>>> } >>>> } >>>> >>>> The MagStaDyn_av_js0_3D formulation gives a resonable solution but Thermal gives weird results. >>>> >>>> I know the ?indheat? example uses T-O formulation for coupling analysis. Are there any reasons to take T-O formulation instead of A-V formulation? >>>> Any ways for A-V formulation? >>>> >>>> Thank you so much. >>>> >>>> Best, >>>> >>>> ABE Hiroshi >>>> from Tokorozawa, JAPAN >>>> >>>> >>>> _______________________________________________ >>>> getdp mailing list >>>> getdp at onelab.info >>>> http://onelab.info/mailman/listinfo/getdp >>> >> >> ABE Hiroshi >> from Tokorozawa, JAPAN >> >> _______________________________________________ >> getdp mailing list >> getdp at onelab.info >> http://onelab.info/mailman/listinfo/getdp > ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: indheat_orig_t20.png Type: image/png Size: 45084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: indheat_orig_t20.png Type: image/png Size: 45084 bytes Desc: not available URL: From payojara1956 at gmail.com Thu Oct 19 01:42:18 2017 From: payojara1956 at gmail.com (Pablo Jara) Date: Wed, 18 Oct 2017 18:42:18 -0500 Subject: [Getdp] eigenvalue problem Message-ID: Hi, I trying to solve the 2d time independent Shrodinger equation in getDp, but I do not understand how to use the eigenvalue solver for this specific example. Please help me with any advice about it, regards, Libre de virus. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Fri Oct 27 08:43:51 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Fri, 27 Oct 2017 15:43:51 +0900 Subject: [Getdp] PostOperation Message-ID: <96FD8CDB-1B4E-463A-9C58-B33B6525FD64@gmail.com> Dear All, I built a Gmsh/GetDP project doing a coupling simulation of thermal and magnetodynamics, refereing to inductor and indheat examples. The simulation works fine now, but I?m stuck in PostOperation to save time series data of transient simulation. Load the ?inductive_heat.pro" file to Gmsh and Run to display the results at each time steps. But the output file, saying ?tThe.pos", only includes the last time step values. It would be caused by the statement: ?LastTimeStepOnly? in Print operation. But without the statement, I got Error : GetDP - Empty solution in DofData 0 The benchmarks, such as ?inductor?, can save the all time series in the pos file. So there should be some mistakes but I couldn?t find my fault in my project files. I would be really obliged if you would point to my mistakes. Please find four files attached in this mail. Thank you very much in advance, Yours sincerely, ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- A non-text attachment was scrubbed... Name: inductive_heat.pro Type: application/octet-stream Size: 12118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inductive_heat.geo Type: application/octet-stream Size: 3806 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: materials.data Type: application/octet-stream Size: 703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inductive_heat_id.geo Type: application/octet-stream Size: 633 bytes Desc: not available URL: From francois.henrotte at uclouvain.be Sun Oct 29 14:22:30 2017 From: francois.henrotte at uclouvain.be (=?Windows-1252?Q?Fran=E7ois_Henrotte?=) Date: Sun, 29 Oct 2017 13:22:30 +0000 Subject: [Getdp] PostOperation In-Reply-To: <96FD8CDB-1B4E-463A-9C58-B33B6525FD64@gmail.com> References: <96FD8CDB-1B4E-463A-9C58-B33B6525FD64@gmail.com> Message-ID: Hello ABE, use the AppendTimeStepToFileName feature, which will generate an output file for each time step. Print[ t, OnElementsOf DomainC, File StrCat[Dir, "tThe", ExtGmsh], LastTimeStepOnly, AppendTimeStepToFileName 1 ] ; Then, you can visualize the time evolution of the tThe field - at the end of the simulation by clicking on the ? Play ? icon ( ? > ? ) in the bottom bar of the GUI - or later in a terminal by invoking $ gmsh IH/tThe_*.pos Hope this helps, Fr. Le 27 oct. 2017 ? 08:43, ABE Hiroshi > a ?crit : Dear All, I built a Gmsh/GetDP project doing a coupling simulation of thermal and magnetodynamics, refereing to inductor and indheat examples. The simulation works fine now, but I?m stuck in PostOperation to save time series data of transient simulation. Load the ?inductive_heat.pro" file to Gmsh and Run to display the results at each time steps. But the output file, saying ?tThe.pos", only includes the last time step values. It would be caused by the statement: ?LastTimeStepOnly? in Print operation. But without the statement, I got Error : GetDP - Empty solution in DofData 0 The benchmarks, such as ?inductor?, can save the all time series in the pos file. So there should be some mistakes but I couldn?t find my fault in my project files. I would be really obliged if you would point to my mistakes. Please find four files attached in this mail. Thank you very much in advance, Yours sincerely, ABE Hiroshi from Tokorozawa, JAPAN _______________________________________________ getdp mailing list getdp at onelab.info http://onelab.info/mailman/listinfo/getdp -- Fran?ois Henrotte Dr Ir - francois.henrotte at uclouvain.be - francois.henrotte at ulg.ac.be UCL - B?t. Euler a.217 - Av. G. Lema?tre 4-6 , B-1348 Louvain-la-Neuve - +32(0)10 47 23 64 ULg - Institut Montefiore I154 - All?e de la D?couverte 10, B-4000 Li?ge - +32(0)4 366 37 36 -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Mon Oct 30 01:31:58 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Mon, 30 Oct 2017 09:31:58 +0900 Subject: [Getdp] PostOperation In-Reply-To: References: <96FD8CDB-1B4E-463A-9C58-B33B6525FD64@gmail.com> Message-ID: Dear Francois Henrotte, and all, Thank you for your info. I appreciate it. I have been wondering why the benchmarks on the onelab site can save the time series file without any explicit PostOperation statement in the ?Resolution?. I guess there should be an ?implicit behaviour? to save the time series data in one ?pos? file but I coudn?t have found the way to invoke the ?implicit behavior?. My purpose is to make animation from pos file so your advice are really helpful. Best Regards, Hiroshi 2017/10/29 22:22?Fran?ois Henrotte ????? > Hello ABE, > > use the AppendTimeStepToFileName feature, > which will generate an output file for each time step. > > Print[ t, OnElementsOf DomainC, File StrCat[Dir, "tThe", ExtGmsh], LastTimeStepOnly, AppendTimeStepToFileName 1 ] ; > > Then, you can visualize the time evolution of the tThe field > - at the end of the simulation by clicking on the ? Play ? icon ( ? > ? ) > in the bottom bar of the GUI > - or later in a terminal by invoking > > $ gmsh IH/tThe_*.pos > > Hope this helps, > > Fr. > > > Le 27 oct. 2017 ? 08:43, ABE Hiroshi a ?crit : > >> Dear All, >> >> I built a Gmsh/GetDP project doing a coupling simulation of thermal and magnetodynamics, refereing to inductor and indheat examples. >> >> The simulation works fine now, but I?m stuck in PostOperation to save time series data of transient simulation. >> Load the ?inductive_heat.pro" file to Gmsh and Run to display the results at each time steps. >> But the output file, saying ?tThe.pos", only includes the last time step values. It would be caused by the statement: ?LastTimeStepOnly? in Print operation. But without the statement, I got >> >> Error : GetDP - Empty solution in DofData 0 >> >> The benchmarks, such as ?inductor?, can save the all time series in the pos file. So there should be some mistakes but I couldn?t find my fault in my project files. >> >> I would be really obliged if you would point to my mistakes. >> Please find four files attached in this mail. >> >> Thank you very much in advance, >> ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexis-hottekilburn at hotmail.com Thu Nov 2 18:48:31 2017 From: Alexis-hottekilburn at hotmail.com (Alexis Hotte) Date: Thu, 2 Nov 2017 17:48:31 +0000 Subject: [Getdp] Eigenvalue problem: " no system is available for eigensolve" Message-ID: Hi, I am trying to create a .pro file to calculate the eigenvalue and electric field of a dielectric sphere, surround by a cubical air box (no pml). So we are solving for the field in two regions (vector helmholtz equation, Laplacian(E)+w^2*E=0.) When I try to run the .pro file, I receive the warning: "DtDt not implemented, using DtDtDof instead" and the error message: "No system available for EigenSolve: check 'DtDt' and 'GenerateSeparate'". I suspect the problem lies in the DtDt in the formulations part, but since the eigenvalue appears in vector helmholtz equation, the time derivative appears instead. Otherwise I'd be putting a constant that must be solved in the equation. It would be very appreciative if someone could verify my file and point me in the right direction. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dielectricsphere2.geo Type: application/octet-stream Size: 1053 bytes Desc: dielectricsphere2.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dielectricsphere2.pro Type: application/octet-stream Size: 2720 bytes Desc: dielectricsphere2.pro URL: From marsic at temf.tu-darmstadt.de Fri Nov 3 09:47:08 2017 From: marsic at temf.tu-darmstadt.de (Marsic, Nicolas) Date: Fri, 3 Nov 2017 08:47:08 +0000 Subject: [Getdp] Eigenvalue problem: " no system is available for eigensolve" In-Reply-To: References: Message-ID: <63d5ec6d-8f06-e8bc-c481-fa93faabb857@temf.tu-darmstadt.de> Hello Alexi, You need to use GenerateSeparate[w] in your Resolution{} instead of Generate[w]. By doing so, GetDP will keep the mass and stiffness matrices separated (he will not sum them up). Afterwards, slepc (or arpack?) will be able to solve the Eigenvalue problem. Hope this helps, Nicolas. On 02/11/17 18:48, Alexis Hotte wrote: > Hi, > > I am trying to create a .pro file to calculate the eigenvalue and > electric field of a dielectric sphere, surround by a cubical air box (no > pml). So we are solving for the field in two regions (vector helmholtz > equation, Laplacian(E)+w^2*E=0.) > > When I try to run the .pro file, I receive the warning: "DtDt not > implemented, using DtDtDof instead" and the error message: > "No system available for EigenSolve: check 'DtDt' and 'GenerateSeparate'". > > I suspect the problem lies in the DtDt in the formulations part, but > since the eigenvalue appears in vector helmholtz equation, the time > derivative appears instead. Otherwise I'd be putting a constant that > must be solved in the equation. > > It would be very appreciative?if someone could verify my file and point > me in the right direction. > > > > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > From Alexis-hottekilburn at hotmail.com Fri Nov 3 19:35:01 2017 From: Alexis-hottekilburn at hotmail.com (Alexis Hotte) Date: Fri, 3 Nov 2017 18:35:01 +0000 Subject: [Getdp] error message: continuously generating "line #: Unknown variable 'nan'" Message-ID: Hi, Thank you very much, Nicolas, your suggestion allowed the software to move past the resolution part. However, when it reaches PostOperation part, I repeatedly receive the error message: " '[my directory]\E_Air_vect.pos', line 2 : Unknown variable 'nan'". This goes on for higher line numbers for a very long time. I was under the impression that the PostOperation that I've written is a fairly normal one (I just the vector and normalized field displayed in both regions). Am I missing something? I'm guessing it's just incompatible with the eigensolve protocol... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dielectricsphere2.geo Type: application/octet-stream Size: 1053 bytes Desc: dielectricsphere2.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dielectricsphere2.pro Type: application/octet-stream Size: 2728 bytes Desc: dielectricsphere2.pro URL: From rdaylwin at uc.cl Sat Nov 4 03:19:43 2017 From: rdaylwin at uc.cl (RUBEN AYLWIN) Date: Fri, 3 Nov 2017 23:19:43 -0300 Subject: [Getdp] GaussLegendre quadrature Message-ID: Dear P.Dular and C.Geuzaine, I'm sorry to bother you, but it seems i've found a bug when trying to use GaussLegendre quadrature. Whenever I try to use more than 3x3x3 points, GetDP crashes and prints out the following message: Error : Number of points should be n^3 with n in [1,100]. I'm including the correspondign section of the code I'm using, just in case I'm making a mistake I'm not seeing, Integration { { Name GG ; Case { { Type GaussLegendre ; Case { { GeoElement Tetrahedron ; NumberOfPoints 64; } } } } } { Name IntPost ; Case { { Type Gauss ; Case { { GeoElement Tetrahedron ; NumberOfPoints 29 ; } } } } } } Thank you for your help! -- R.Aylwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From marsic at temf.tu-darmstadt.de Mon Nov 6 16:20:24 2017 From: marsic at temf.tu-darmstadt.de (Marsic, Nicolas) Date: Mon, 6 Nov 2017 15:20:24 +0000 Subject: [Getdp] error message: continuously generating "line #: Unknown variable 'nan'" In-Reply-To: References: Message-ID: <556fbed0-787a-45e7-a5fa-5bff6ecc3556@temf.tu-darmstadt.de> Hello, I'm unfortunately not able to reproduce this bug. However, I had to reduce the mesh size... Do you have the same problem with a coarser mesh? Do you know which library GetDP uses for the eigenproblem (Arpack or SLPEc)? If you don't know, can you rerun your example with the -slepc argument? By the way, the spectral shift is a bit low (-1). In my test, I used EigenSolve[w,10,-1e6,0]. I get a fundamental mode around 130Hz. On 03/11/17 19:35, Alexis Hotte wrote: > Hi, > > Thank you very much, Nicolas, your suggestion allowed the software to > move past the resolution part. > > However, when it reaches PostOperation part, I repeatedly receive the > error message: " '[my directory]\E_Air_vect.pos', line 2 : Unknown > variable 'nan'". This goes on for higher line numbers for a very long > time.?I was under the impression that the PostOperation that I've > written is a fairly normal one (I just the vector and normalized field > displayed in both regions). Am I missing something? I'm guessing it's > just incompatible with the eigensolve protocol... > > > > > _______________________________________________ > getdp mailing list > getdp at onelab.info > http://onelab.info/mailman/listinfo/getdp > From Alexis-hottekilburn at hotmail.com Mon Nov 20 17:22:42 2017 From: Alexis-hottekilburn at hotmail.com (Alexis Hotte) Date: Mon, 20 Nov 2017 16:22:42 +0000 Subject: [Getdp] Questions about frequency/eigenvalues and units. Message-ID: Alexis Hotte a partag? des fichiers OneDrive avec vous. Pour les afficher, cliquez sur les liens ci-dessous. [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png] attachment.pro [https://r1.res.office365.com/owa/prem/images/dc-generic_20.png] attachment.geo Hello, I have here a .pro file that attempts the calculate the eigenvalue(s) of a dielectric sphere (and solve the vector helmholtz equation). In the resolution, I ask it to solve for 10 eigenvalues. Is there a way to display the field that corresponds to a certain eigenvalue (like the first or fifth, for example) in either PostProcessing or PostOperation? Speaking of eigenvalues, when I try to refer to it in PostProcessing (w from Eigensolve), I get the error message that it is an unknown constant. I'm trying to get the magnetic field from the electric field, which involves taking the curl and multiplying by frequency. Also, when I ran the file without the above magnetic field, I get a very low real part and a quite high negative imaginary part. Are the units of the eigenvalue Hz by default, or am I missing something? What could account for the lower than expected real part? Thank you, Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mang.cai at yahoo.de Sun Nov 26 19:04:24 2017 From: mang.cai at yahoo.de (Mang Cai) Date: Sun, 26 Nov 2017 18:04:24 +0000 (UTC) Subject: [Getdp] field quantity along circular line References: <2142763282.4659940.1511719464737.ref@mail.yahoo.com> Message-ID: <2142763282.4659940.1511719464737@mail.yahoo.com> Dear getdp-team: I want to use getdp to calculate e-motor. Is it anyway to get the B-field component along circular line,just like in the middle of the air-gap or in the middle of the stator yoke? thank you for the help,best regards,Mang ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.j.north at bristol.ac.uk Mon Dec 4 16:08:23 2017 From: d.j.north at bristol.ac.uk (Dominic North) Date: Mon, 4 Dec 2017 15:08:23 +0000 Subject: [Getdp] NaNs instead of Values... Message-ID: Hi everyone, I'd like to ask if anyone can answer this, or has similar issues please. Is there any reason a GetDP script would return good results for larger mesh sizes (0.4 to 5.0), but a list of NaNs for the calculated values when the mesh size is reduced (0.2 characteristic length)? To be clear, the program runs fine, the mesh is computed ok, but for each row in the results Gnuplot table, there is type, XYZ coordinates etc (all fine), but 'NaN' in the 'Values' column. Only when the characteristic length is set to low values. (They're rather long, complex .pro and .geo files, otherwise I would attach them here!) Any help is much appreciated, thanks. Best regards, Dominic North PhD student Electrical Energy Management Group Bristol University -------------- next part -------------- An HTML attachment was scrubbed... URL: From habe36 at gmail.com Thu Dec 7 13:55:38 2017 From: habe36 at gmail.com (ABE Hiroshi) Date: Thu, 7 Dec 2017 21:55:38 +0900 Subject: [Getdp] NaNs instead of Values... In-Reply-To: References: Message-ID: Hi Dominic, GetDP uses MUMPS solver for the linear system as default. It might be possible that the solver couldn't work properly for your large meshes. Other solver like GMRES, CGSTAB might resolve your problem. Hope this helps. 2017/12/05 0:08?Dominic North ????? > Hi everyone, > I?d like to ask if anyone can answer this, or has similar issues please. > > Is there any reason a GetDP script would return good results for larger mesh sizes (0.4 to 5.0), but a list of NaNs for the calculated values when the mesh size is reduced (0.2 characteristic length)? > > To be clear, the program runs fine, the mesh is computed ok, but for each row in the results Gnuplot table, there is type, XYZ coordinates etc (all fine), but ?NaN? in the ?Values? column. Only when the characteristic length is set to low values. > > (They?re rather long, complex .pro and .geo files, otherwise I would attach them here!) > > > Any help is much appreciated, thanks. > > Best regards, > Dominic North ABE Hiroshi from Tokorozawa, JAPAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From vskych at gmail.com Fri Dec 15 08:12:31 2017 From: vskych at gmail.com (=?UTF-8?B?0JDRgNGC0LXQvCDQpdC+0YDQvtGI0LXQsg==?=) Date: Fri, 15 Dec 2017 10:12:31 +0300 Subject: [Getdp] Time-dependent print-option "Skin" Message-ID: Hello! Is it possible to apply the print-option "Skin" for all time-steps? For example, if use "OnElementsOf" for a time-dependent problem, then the output file will contain results for all time-step: Print[ T, OnElementsOf #{COPPERWIRE, CONTWIRE} , File "map_cont.pos", Name "T(C), Contact"]; But if apply the print-option "Skin", the output file contain results only for the first step: Print[ T, OnElementsOf #{COPPERWIRE, CONTWIRE} , Skin, File "map_cont.pos", Name "T(C), Contact"]; Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlon.s.alcantara at outlook.com.br Fri Dec 15 17:51:37 2017 From: marlon.s.alcantara at outlook.com.br (Marlon De Souza Alc?ntara) Date: Fri, 15 Dec 2017 16:51:37 +0000 Subject: [Getdp] getdp@onelab.info Message-ID: Good afternoon everyone, I'm new to GetDP and I'm apprehending a program structure. So with this example, I can not display the results in an inactive dialog box. The problem I am studying is attached here. It is an example available without a website but with a change, as it is available as already said. I define parameter S11, in the post processing step. {Name pos_eS; NameOfFormulation eFormulation; Quantity{ {Name intPort~{(1)} ; Value{Integral{ [ePort~{1}[]*Conj[ePort~{1}[]]] ; In Port~{1}; Jacobian Jac ; Integration I1;}}} {Name xS~{(1)} ; Value{Integral{ [({e}-ePort~{1}[])*Conj[ePort~{1}[]]] ; In Port~{1}; Jacobian Jac ; Integration I1 ;}}} {Name xS~{(2)} ; Value{Integral{ [{e}*Conj[ePort~{1}[]]] ; In Port~{2}; Jacobian Jac ; Integration I1 ;}}} } } But when I show the value in a dialog box says the constant is unknown. If(Excitation == 1) { Name Get_S ; NameOfPostProcessing pos_eS ; Operation { DefineConstant[ R = {intPort~{(1)}, Name "Input/5Output/1Reflection ",Color "LightYellow"}]; Print[ intPort~{(1)}, OnGlobal, Name "/Input/3Signal/3Cutoff frequency [Hz]", Color "LightYellow" ]; // Print[ intPort~{(1)}, OnRegion Port~{1}, Format Table, File "res/um_middle.txt", SendToServer "Output/Middle diplacement [m]"{0}, Color "LightYellow" ]; }} Else EndIf Enviado do Email para Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: waveguide2D.geo Type: application/octet-stream Size: 1563 bytes Desc: waveguide2D.geo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: waveguide2D.pro Type: application/octet-stream Size: 9201 bytes Desc: waveguide2D.pro URL: