getdp issueshttps://gitlab.onelab.info/getdp/getdp/-/issues2022-03-25T10:58:51Zhttps://gitlab.onelab.info/getdp/getdp/-/issues/1173D Moving Band2022-03-25T10:58:51ZViktor -3D Moving BandRelated to #76.
Hello @Theom ,
were you able to find a solution for the 3d moving band, or do you remesh as suggested by @geuzaine ? I am trying as well to model axial flux machines, but I am still quiet on the beginning of understandin...Related to #76.
Hello @Theom ,
were you able to find a solution for the 3d moving band, or do you remesh as suggested by @geuzaine ? I am trying as well to model axial flux machines, but I am still quiet on the beginning of understanding onelabs concepts. Perhaps you can provide an example?
Best regards,
Viktorhttps://gitlab.onelab.info/getdp/getdp/-/issues/155About Freq and Time domain`s simulation2023-06-26T14:48:55ZOthman AbujazarAbout Freq and Time domain`s simulationHello Everyone,
I have recently been exploring the inductor example in ONELAB, and there's a particular observation that has caught my attention. In the frequency domain analysis, I noticed that the Joule losses correspond to the peak v...Hello Everyone,
I have recently been exploring the inductor example in ONELAB, and there's a particular observation that has caught my attention. In the frequency domain analysis, I noticed that the Joule losses correspond to the peak value found in the time domain simulation. This has raised a question for me, as I originally anticipated the losses in the frequency domain to align with the average (or RMS value) from the time domain simulation. I am currently investigating this discrepancy and would appreciate any insights or clarification.
Thanks
Othman Abujazarhttps://gitlab.onelab.info/getdp/getdp/-/issues/4access Time & TimeImag in post-processing2017-03-27T09:20:53ZChristophe Geuzaineaccess Time & TimeImag in post-processingSubject says it all (mostly useful for eigenvalues Re/Im)Subject says it all (mostly useful for eigenvalues Re/Im)https://gitlab.onelab.info/getdp/getdp/-/issues/18Add function that gives size of geometric bounding box2017-03-27T09:20:40ZChristophe GeuzaineAdd function that gives size of geometric bounding boxWe should add a function that returns the values of the geom bbox stored in
GeoData_P->Xmin, etc.
This would be useful for determining regularization constantsWe should add a function that returns the values of the geom bbox stored in
GeoData_P->Xmin, etc.
This would be useful for determining regularization constantshttps://gitlab.onelab.info/getdp/getdp/-/issues/78ARPACK96 doesn't work for eigenvalue problem (elasticity 3D modal)2021-04-18T17:21:51ZAlexander ShendiARPACK96 doesn't work for eigenvalue problem (elasticity 3D modal)ARPACK96 doesn't converge for me for modal elasticity 3D problem. SLEPC does. Tested on Debian Linux/aarch64 and OpenBSD-current amd64.
I initially used ARPACK96, because it was available from ports for OpenBSD.ARPACK96 doesn't converge for me for modal elasticity 3D problem. SLEPC does. Tested on Debian Linux/aarch64 and OpenBSD-current amd64.
I initially used ARPACK96, because it was available from ports for OpenBSD.https://gitlab.onelab.info/getdp/getdp/-/issues/110Auto-symmetrization of Galerkin terms2023-09-22T07:24:04ZChristophe GeuzaineAuto-symmetrization of Galerkin termsWe should fix the auto-symmetrization of terms by being "safe", i.e. only auto-symmetrize with tensor-valued functions if the term involves symmetric tensors.
See https://gitlab.onelab.info/getdp/getdp/-/blob/master/Kernel/Cal_GalerkinT...We should fix the auto-symmetrization of terms by being "safe", i.e. only auto-symmetrize with tensor-valued functions if the term involves symmetric tensors.
See https://gitlab.onelab.info/getdp/getdp/-/blob/master/Kernel/Cal_GalerkinTermOfFemEquation.cpp#L72
@julien.dularhttps://gitlab.onelab.info/getdp/getdp/-/issues/70Automatic https-forwarding not working2021-01-26T21:10:41ZUser_NAutomatic https-forwarding not workingWhen visiting getdp.info, there is no automatic forwarding to https://getdp.info/ (but let's encrypt certificate is available).
And even when using https://getdp.info/ some graphic parts are not using https.When visiting getdp.info, there is no automatic forwarding to https://getdp.info/ (but let's encrypt certificate is available).
And even when using https://getdp.info/ some graphic parts are not using https.https://gitlab.onelab.info/getdp/getdp/-/issues/154Average in time domain simulation2023-06-15T11:12:35ZOthman AbujazarAverage in time domain simulationHi,
I want to ask if it is possible to get the average in time domain simulation. for example, ![joule](/uploads/f6f19bcdd98e47a35ff8992af5f6505e/joule.png)
Could I make a time Integral or sum the Joule losses over the period time?
tha...Hi,
I want to ask if it is possible to get the average in time domain simulation. for example, ![joule](/uploads/f6f19bcdd98e47a35ff8992af5f6505e/joule.png)
Could I make a time Integral or sum the Joule losses over the period time?
thank youhttps://gitlab.onelab.info/getdp/getdp/-/issues/159Calculate resistance in inductor example - problem with current density in co...2023-08-31T08:43:21ZPatrickCalculate resistance in inductor example - problem with current density in conductorHello,
I would like to calculate the resistance in the inductor example. However, in the current setup, it seems that the eddy current is only being simulated in the core and not in the coil.
**Approach:** To address this limitation, I...Hello,
I would like to calculate the resistance in the inductor example. However, in the current setup, it seems that the eddy current is only being simulated in the core and not in the coil.
**Approach:** To address this limitation, I have included the coil within DomainC to simulate the skin effect within the coil itself.
**Problem:** Unfortunately, the current density, represented as jAV + js1, does not appear to be correct.
**Question:** I am seeking guidance on how to modify the example to accurately simulate both the skin and proximity effects within the coil.
**Possible Solution:** One approach I am considering is defining a voltage between two closely spaced surfaces within the coil and utilizing a circuit definition to model these effects. Does this approach seem feasible, and if so, how should I go about implementing it?
I appreciate any insights or suggestions for improving this simulation.https://gitlab.onelab.info/getdp/getdp/-/issues/3complex conjugation problem with sparskit2020-05-29T15:44:21ZChristophe Geuzainecomplex conjugation problem with sparskitWith sparsekit and 3D modelling in getdp I found an
error. If one includes terms like
Galerkin { [ Einc[], {E} ]; In port; Integration I1;
Jacobian Jac;}
Where Einc is purely imaginary then sparsekit complex conjugates i...With sparsekit and 3D modelling in getdp I found an
error. If one includes terms like
Galerkin { [ Einc[], {E} ]; In port; Integration I1;
Jacobian Jac;}
Where Einc is purely imaginary then sparsekit complex conjugates it.
It is only a problem in 3D. In 2D it does not exist. The problem
also disappers with petsc.https://gitlab.onelab.info/getdp/getdp/-/issues/81Computation times on Linux aarch64 vs OpenBSD amd642021-05-14T12:34:55ZAlexander ShendiComputation times on Linux aarch64 vs OpenBSD amd64Hello gentle getdp folks,
I have observed rather lqrge (ca. one order of magnitude) differences in calculation times (both wall and cpu). See the attached text file for more details.
The times reported are:
1. Start of program
2. After...Hello gentle getdp folks,
I have observed rather lqrge (ca. one order of magnitude) differences in calculation times (both wall and cpu). See the attached text file for more details.
The times reported are:
1. Start of program
2. After eigenvalue calculation
3. After Postprocessing
4. End of program
There seems to a difference between wall clock time and cpu time during postprocessing on OpenBSD. On OpenBSD I moved the calculation directory
to a RAM disk, but that didn't help much.
I'm mainly looking for further hints on how to proceed with debugging
the problem. I will also be glad to supply further information,
if needed.
Attachements:
[out.001.txt](/uploads/5fb77a75e989c2dc3dc2e9c35a56e17d/out.001.txt)![OpenBSD_und_Linux](/uploads/30e2f37946800e7e1ef54a56f0de71fa/OpenBSD_und_Linux.png)https://gitlab.onelab.info/getdp/getdp/-/issues/55Computing rotor speed and position2019-08-01T05:44:30ZCássio Krugerkrugercassio@gmail.comComputing rotor speed and positionHello guys! I've been work on a magnetic gear project (https://github.com/CassioKruger/PDD-pure) and I'm having trouble to compute the velocity of the moving bands. I took the "machine_magstadyn_a.pro" file to base my project and added s...Hello guys! I've been work on a magnetic gear project (https://github.com/CassioKruger/PDD-pure) and I'm having trouble to compute the velocity of the moving bands. I took the "machine_magstadyn_a.pro" file to base my project and added some modifications to use it with 2 rotors instead of 1.
There is a gear ratio between both rotors, so I made this in my .pro file:
```
// pdd gear ratio:
// pH*wH + pL*wL = nP*wP
// wH is the speed of the inner rotor
// wL is the speed of the outer rotor
// wP is the speed of the modulators
// When one of the three parts of the gear is stationary, there will be a constant relation or gear ratio
// between the speeds of other two parts.
// considering that the outer rotor is stationary, the gear ratio becomes:
// -> pH*wH = nP*wP
// -> Gr = pH/nP = wP/wH
// -> gear ratio = nbr of poles at rotor 1 / nbr of modulators
// in this case, the nbr of modulators is equal to the nbr of poles at the outer rotor, so:
gear_ratio = NbrPolesInModel/NbrSectStatorMag;
delta_theta[] = delta_theta_deg * deg2rad ; //rotor 1 step
delta_theta2[] = delta_theta[] * gear_ratio ; //rotor 2 step
```
those "delta_theta[]" should be the step of each rotor to use with "ChangeOfCoordinates" inside the timeloop of the "machine_magstadyn_a_2rotors.pro" file, like this:
```
ChangeOfCoordinates[ NodesOf[Rotor_Moving], RotatePZ[delta_theta[]]];
ChangeOfCoordinates[ NodesOf[Rotor2_Moving], RotatePZ[delta_theta2[]]];
```
and that's working nice, the gear ration is clearly seen at the simulation. But the thing that I'm couldn't figure out is how to compute the correct speed and position of each rotor, so I can show it with graphs and prove that my model is working. I've made this:
-First, I've declared a "DomainKin2", because now there is 2 parts moving
-Then, inside the "Constraint{}" I made this:
```
Constraint{
...
...
...
//Kinetics
{ Name CurrentPosition ; // [m]
Case {
{ Region DomainKin ; Type Init ; Value ($PreviousPosition = 0) ; }
}
}
{ Name CurrentVelocity ; // [rad/s]
Case {
{ Region DomainKin ; Type Init ; Value ($PreviousVelocity = 0) ; }
}
}
//Kinetics - MOVING BAND 2
{ Name CurrentPosition2 ; // [m]
Case {
{ Region DomainKin2 ; Type Init ; Value ($PreviousPosition2 = 0) ; }
}
}
{ Name CurrentVelocity2 ; // [rad/s]
Case {
{ Region DomainKin2 ; Type Init ; Value ($PreviousVelocity2 = 0) ; }
}
}
}
```
-After that, I did the same to "FunctionSpace{}":
```
FunctionSpace{
...
...
...
// For mechanical equation
{ Name Position ; Type Scalar ;
BasisFunction {
{ Name sr ; NameOfCoef pr ; Function BF_Region ;
Support DomainKin ; Entity DomainKin ; }
}
GlobalQuantity {
{ Name P ; Type AliasOf ; NameOfCoef pr ; }
}
Constraint {
{ NameOfCoef P ; EntityType Region ; NameOfConstraint CurrentPosition ; }
}
}
{ Name Velocity ; Type Scalar ;
BasisFunction {
{ Name sr ; NameOfCoef vr ; Function BF_Region ;
Support DomainKin ; Entity DomainKin ; } }
GlobalQuantity {
{ Name V ; Type AliasOf ; NameOfCoef vr ; }
}
Constraint {
{ NameOfCoef V ; EntityType Region ; NameOfConstraint CurrentVelocity ; }
}
}
// For mechanical equation - MOVING BAND 2
{ Name Position2 ; Type Scalar ;
BasisFunction {
{ Name sr ; NameOfCoef pr2 ; Function BF_Region ;
Support DomainKin2 ; Entity DomainKin2 ; }
}
GlobalQuantity {
{ Name P2 ; Type AliasOf ; NameOfCoef pr2 ; }
}
Constraint {
{ NameOfCoef P2 ; EntityType Region ; NameOfConstraint CurrentPosition2 ; }
}
}
{ Name Velocity2 ; Type Scalar ;
BasisFunction {
{ Name sr ; NameOfCoef vr2 ; Function BF_Region ;
Support DomainKin2 ; Entity DomainKin2 ; } }
GlobalQuantity {
{ Name V2 ; Type AliasOf ; NameOfCoef vr2 ; }
}
Constraint {
{ NameOfCoef V2 ; EntityType Region ; NameOfConstraint CurrentVelocity2 ; }
}
}
}
```
-In the "Formulation{}", I did this:
```
Formulation{
...
...
...
// Mechanics
{ Name Mechanical ; Type FemEquation ;
Quantity {
{ Name V ; Type Global ; NameOfSpace Velocity [V] ; } // velocity
{ Name P ; Type Global ; NameOfSpace Position [P] ; } // position
{ Name V2 ; Type Global ; NameOfSpace Velocity2 [V2] ; } // velocity MB2
{ Name P2 ; Type Global ; NameOfSpace Position2 [P2] ; } // position MB2
}
Equation {
GlobalTerm { DtDof [ /*Inertia **/ Dof{V} , {V} ] ; In DomainKin ; }
//GlobalTerm { [ Friction[] * Dof{V} , {V} ] ; In DomainKin ; }
GlobalTerm { [ Torque_mec[], {V} ] ; In DomainKin ; }
GlobalTerm { [ Torque_mag[] , {V} ] ; In DomainKin ; }
GlobalTerm { DtDof [ Dof{P} , {P} ] ; In DomainKin ; }
GlobalTerm { [-Dof{V} , {P} ] ; In DomainKin ; }
//---------------------------------------------------------------//
GlobalTerm { DtDof [ /*Inertia*0.7 **/ Dof{V2} , {V2} ] ; In DomainKin2 ; }
//GlobalTerm { [ Friction[] * Dof{V2} , {V2} ] ; In DomainKin2 ; }
GlobalTerm { [ Torque_mec[] , {V2} ] ; In DomainKin2 ; }
GlobalTerm { [ Torque_mag[] , {V2} ] ; In DomainKin2 ; }
GlobalTerm { DtDof [ Dof{P2} , {P2} ] ; In DomainKin2 ; }
GlobalTerm { [-Dof{V2} , {P2} ] ; In DomainKin2 ; }
}
}
}
```
-And, finally, in the "PostProcessing{}" I did this:
```
PostProcessing{
...
...
...
{ Name Mechanical ; NameOfFormulation Mechanical ;
PostQuantity {
{ Name P ; Value { Term { [ {P} ] ; In DomainKin ; } } } // Position [rad]
{ Name Pdeg ; Value { Term { [ {P}*180/Pi ] ; In DomainKin ; } } } // Position [deg]
{ Name V ; Value { Term { [ {V} ] ; In DomainKin ; } } } // Velocity [rad/s]
{ Name Vrpm ; Value { Term { [ {V}*30/Pi ] ; In DomainKin ; } } } // Velocity [rpm]
//------------------------------------------------------------------------------------//
//MB2
{ Name P2 ; Value { Term { [ {P2} ] ; In DomainKin2 ; } } } // Position [rad]
{ Name Pdeg2 ; Value { Term { [ {P2}*180/Pi ] ; In DomainKin2 ; } } } // Position [deg]
{ Name V2 ; Value { Term { [ {V2} ] ; In DomainKin2 ; } } } // Velocity [rad/s]
{ Name Vrpm2 ; Value { Term { [ {V2}*30/Pi ] ; In DomainKin2 ; } } } // Velocity [rpm]
}
}
}
```
After that, is just the PostOperation stuff to creat .dat files to plot the results...
I'm sorry for the long issue, but I REALLY can't figure out how to compute those.
Thanks in advance!!!https://gitlab.onelab.info/getdp/getdp/-/issues/160Delete PostProcessing Views Before PostOperation2023-10-24T03:40:16ZStuart BarthDelete PostProcessing Views Before PostOperationPost-processing views are generally created in the `PostOperation` step by using the `Print[ `_`post-quantity-id`_ `<[`_`group-def`_`]>, `_`print-support`_ `<,`_`print-option`_`> ... ]` command. **gmsh** has a command `Delete View[`_`exp...Post-processing views are generally created in the `PostOperation` step by using the `Print[ `_`post-quantity-id`_ `<[`_`group-def`_`]>, `_`print-support`_ `<,`_`print-option`_`> ... ]` command. **gmsh** has a command `Delete View[`_`expression`_`];` that deletes these post-processing views at the index of _`expression`_. I want to run my simulation multiple times, but also clear any existing post-processing views before starting a new simlation. I think the easiset way to do this is in **getdp**'s `PostOperation` step, before the `Print[]` commands are called.
In [rhombus.pro](https://gitlab.onelab.info/doc/models/-/blob/master/BlochPeriodicWaveguides/rhombus.pro#L286), we see that the `Delete View[ ]` is mentioned to do precisely this -- but not explictly called, and indeed, **getdp** doesn't seem to recognize the command here if not `Echo`'d.
Is there some way to delete the postprocessing views before a new simulation is run?
Thank you!https://gitlab.onelab.info/getdp/getdp/-/issues/149Eigenmode problem with DtDof operator (and not DtDtDof)2023-03-02T10:26:47ZWolfgang SuttropEigenmode problem with DtDof operator (and not DtDtDof)Dear all,
I am trying to find eigenmodes for an eddy current problem (Magnetodynamics a-v formulation), i.e. for first order time derivative (DtDof). I hope to obtain as eigenvalues the inverse decay time constants for current density e...Dear all,
I am trying to find eigenmodes for an eddy current problem (Magnetodynamics a-v formulation), i.e. for first order time derivative (DtDof). I hope to obtain as eigenvalues the inverse decay time constants for current density eigenmodes of a passive conductor. A simple demonstration is the 2D Magnetodynamic example (chapter 8.3 of the getDP manual) where I added this resolution section:
```
{ Name Eigenmode ;
System {
{ Name EigenSys ; NameOfFormulation Magnetodynamics_av_2D ; Type ComplexValue ; }
}
Operation {
GenerateSeparate[EigenSys] ;
EigenSolve[EigenSys, NbEigenvalues, EigenvalShiftRe, EigenvalShiftIm] ;
SaveSolutions[EigenSys] ;
}
}
```
(with NbEigenvalues=4, EigenvalShiftRe=0.0, EigenvalShiftIm=0.0) which results in this error:
`Error : GetDP - No System available for EigenSolve: check 'DtDt' and 'GenerateSeparate'`
I am using getDP version 3.5.0, both with and without the `-slepc`option.
Replacing `DtDof`with `DtDtDof`in the formulation removes the error and produces a result that looks like eigenmodes of an oscillatory system, similar to what you'd expect from the various Helmholtz equation examples.
Curiously, source code comments in both src/kernel/Eigensolve_ARPACK.cpp:267 and src/kernel/Eigensolve_SLEPc.cpp:1266 seem to indicate that first order time derivatives should be allowed.
Am I attempting something stupid?
Thanks in advance for any advice ...
Greetings
Wolfganghttps://gitlab.onelab.info/getdp/getdp/-/issues/88Elasticity Module - Deformed Edge Length2021-07-12T20:01:24ZKeegan JauchElasticity Module - Deformed Edge LengthHi,
I am applying the Onelab module to solve elastic static structural simulations. Is there a way to return the deformed length of a physical curve after GetDP runs the simulation? I have looked through the documentation and have no...Hi,
I am applying the Onelab module to solve elastic static structural simulations. Is there a way to return the deformed length of a physical curve after GetDP runs the simulation? I have looked through the documentation and have not found a way to do this.
Thanks!
Keeganhttps://gitlab.onelab.info/getdp/getdp/-/issues/148Elasticity polar coordinates and Lagrange multipliers2023-09-13T19:06:58ZAlexElasticity polar coordinates and Lagrange multipliersDear all,
I want to run an elasticity simulation (centrifugal force) for a rotor with interior magnets (comparable with https://gitlab.onelab.info/getdp/getdp/-/issues/113). But at the moment, I have some trouble to set the correct cons...Dear all,
I want to run an elasticity simulation (centrifugal force) for a rotor with interior magnets (comparable with https://gitlab.onelab.info/getdp/getdp/-/issues/113). But at the moment, I have some trouble to set the correct constraints. I know about two possible methods:
1. using polar coordinates to set the constraints
2. using lagrange multipliers to set the constraints normally in Cartesian coordinates
For simplicity, I started with a rotating disc. But my implementation of both methods doesn't work. Maybe someone could give me a hint for this? I attached the .geo and .pro files of the rotating disc. I need a radial constraint at the inner radius (u_r = 0) and symmetric constraints at the two lines (left: u_x = 0, bottom: u_y = 0), of course, the symmetric ones are easy. But later I will have lines that are not parallel to the x- and y-axis.
Another point is that I want to model the contact between interior magnets and steel (also like in the other issue). Is it correct, that Lagrange multipliers can be used for this, too? If yes, how could I do that?
I would appreciate any help.
Best regards,
Alex
[Scheibe.geo](/uploads/c30cc4e0dadfd59ed70e92f0922a238c/Scheibe.geo)
[Scheibe.pro](/uploads/18626328f98a1a0ad62f24b5ea38f51e/Scheibe.pro)https://gitlab.onelab.info/getdp/getdp/-/issues/92Error : Null determinant in 'ChangeOfCoord_Form2P'2021-07-19T18:40:19ZPeter KisError : Null determinant in 'ChangeOfCoord_Form2P'An error is generated in [Magnetostatics example](https://getdp.info/doc/texinfo/getdp.html#Magnetostatic-problem) in AxiSymmetric case, when VolAxiSquSphShell and VolAxiSqu Jacobians are used.
The problem is at curl computation in PostP...An error is generated in [Magnetostatics example](https://getdp.info/doc/texinfo/getdp.html#Magnetostatic-problem) in AxiSymmetric case, when VolAxiSquSphShell and VolAxiSqu Jacobians are used.
The problem is at curl computation in PostProcessing part. I don't see the error message for other Jacobians.
Error : Null determinant in 'ChangeOfCoord_Form2P'https://gitlab.onelab.info/getdp/getdp/-/issues/130error: cannot convert ‘int*’ to ‘PetscInt*’2022-05-28T14:48:48Zgerard henryerror: cannot convert ‘int*’ to ‘PetscInt*’Hello all,
Compiling latest release 3.5.0 with petsc configured with "--with-64-bit-indices", we got these errors that stop the compilation, even with adding the flag "-fpermissive":
`
/home/henry/projets/getdp-3.5.0-source/src/kernel/...Hello all,
Compiling latest release 3.5.0 with petsc configured with "--with-64-bit-indices", we got these errors that stop the compilation, even with adding the flag "-fpermissive":
`
/home/henry/projets/getdp-3.5.0-source/src/kernel/EigenSolve_SLEPC.cpp:516:35: error: cannot convert ‘int*’ to ‘PetscInt*’ {aka ‘long int*’} 516 | _try(EPSGetIterationNumber(eps, &its)); | ^~~~ | | | int* In file included from /home/henry/projets/getdp-3.5.0-source/src/kernel/EigenSolve_SLEPC.cpp:48: /home/henry/projets/slepc-3.17.1-int8/include/slepceps.h:252:55: note: initializing argument 2 of ‘PetscErrorCode EPSGetIterationNumber(EPS, PetscInt*)’ 252 | SLEPC_EXTERN PetscErrorCode EPSGetIterationNumber(EPS,PetscInt*);
`
According to us, it seems that PetscInt needs "long int" but in the source, there is "int".
Thanks in advance for help,
Gérard & Gilleshttps://gitlab.onelab.info/getdp/getdp/-/issues/111force density on stator ring2022-01-09T09:10:03ZMarc Schöningforce density on stator ringHi all,
I have a small problem to calculate the force density on a stator ring of an inner rotor airgap winding.
Here is the cross section:
![geo_commented](/uploads/a4830751037fd75409d0df109139852f/geo_commented.png)
I work on base o...Hi all,
I have a small problem to calculate the force density on a stator ring of an inner rotor airgap winding.
Here is the cross section:
![geo_commented](/uploads/a4830751037fd75409d0df109139852f/geo_commented.png)
I work on base of the machine_magstadyn_a.pro and placed a Physical Line on the inner stator diameter and added it as Region to a Domain called DomainLineForce. Then there is a new Postprocessing:
{ Name LineForce;
Value {
Term { [ (T_max[{d a}] * XYZ[]) ];
In Domain; Jacobian Vol; }
}
}
and finally a PostOperation:
Print[ LineForce, OnGrid DomainLineForce, File "LineForce.pos", LastTimeStepOnly, AppendTimeStepToFileName 1];
The result is here:
![result](/uploads/7ad5955a032552488a274e1ff6eb5661/result.png)
What surprises me is, that according to theory, I would expect the force vector to point to the airgap with low permeability and not to the stator yoke with high permeability.
Did I messed up the Postprocessing equation?
Thanks in advance.https://gitlab.onelab.info/getdp/getdp/-/issues/10generalize localterm2017-08-05T12:01:19ZChristophe Geuzainegeneralize localtermgeneralize localterm (equation part should call Cal_vBFxDof)generalize localterm (equation part should call Cal_vBFxDof)