Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools

You are here: metafor.ltas.ulg.ac.be » doc » Documentation » Automatic Remeshing Process
Trace:
doc:user:remeshing:remeshing

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
doc:user:remeshing:remeshing [2016/06/13 16:36] – [CopyRemesher] jorisdoc:user:remeshing:remeshing [2016/06/14 18:15] – [Options] joris
Line 29: Line 29:
  
 Which is why all of this has been kindly automatized, so that you just have a few settings to define, click on execute, and just sit back, relax, and enjoy the beauty of FENRIR ! Which is why all of this has been kindly automatized, so that you just have a few settings to define, click on execute, and just sit back, relax, and enjoy the beauty of FENRIR !
-===== How does FENRIR work ? =====+===== How does remeshing work ? =====
  
 First, you need to have an operational 2D test case, and the will to introduce remeshing into it.  First, you need to have an operational 2D test case, and the will to introduce remeshing into it. 
Line 258: Line 258:
                          
         autoRemesh.setBalancing(True)         autoRemesh.setBalancing(True)
-            +     
 +        autoRemesh.makeAnim = False 
 +    
         autoRemesh.execute()         autoRemesh.execute()
                  
Line 272: Line 274:
   * ''setInteractionToPostStep'' gives to FENRIR the user number of the interaction on which post-remeshing operations should be executed (typically, any contact interaction), here number 1.   * ''setInteractionToPostStep'' gives to FENRIR the user number of the interaction on which post-remeshing operations should be executed (typically, any contact interaction), here number 1.
      
-  * Finally, the line ''autoRemesh.setBalancing(True)'' is the magical ingredient that makes everything taste better... I will talk more about this in a [[#Balancing|following section]].+  * The line ''autoRemesh.setBalancing(True)'' is the magical ingredient that makes everything taste better... I will talk more about this in a [[#Balancing|following section]]. 
 + 
 +  * Finally, the line ''autoRemesh.makeAnim = False'' indicates that we have no wish to make a save a picture every time that a fac is saved (to make an anim later on). If set to ''True'', then after each time integration, all facs will be loaded and a screenshot will be saved as a .bmp in the folder Anim, located in the workspace, just as is traditionally done when clicking on the button ''makeAnimation'' in Metafor GUI.
  
 Now that you have altered your test case to include remeshing, and that you have defined this little script, all that remains is to launch Metafor and execute your script (execute, not load/meta). Everything should work out perfectly. Now that you have altered your test case to include remeshing, and that you have defined this little script, all that remains is to launch Metafor and execute your script (execute, not load/meta). Everything should work out perfectly.
Line 301: Line 305:
 ==== Changing the critical remeshing value during the computation ==== ==== Changing the critical remeshing value during the computation ====
  
-It may be possible that we want to change the critical value after a few remeshing. If you recall, this value is defined in the [[#getParameters()|''getParameters()'' function of the script]].+It may be possible that we want to change the critical value after a few remeshing (see for example ''apps.remeshing2.fullAuto.cont2bRemeshing''). If you recall, this value is defined in the [[#getParameters()|''getParameters()'' function of the script]].
  
 However, since the same two files are used to generate all the remeshing, it is not possible to know how far in the computation we are. But to change the critical value, we need to know whether the current integration is the first or the tenth. However, since the same two files are used to generate all the remeshing, it is not possible to know how far in the computation we are. But to change the critical value, we need to know whether the current integration is the first or the tenth.
Line 335: Line 339:
 ==== Changing mesh density during the computation ==== ==== Changing mesh density during the computation ====
  
-Actually, the key ''p['integrationNumber']'' can be used to modify any and all parameters during the computation. For example, if we want to double the mesh density after two remeshing, we simply add in the ''getParameters()'' function of the script (after the update !) : +Actually, the key ''p['integrationNumber']'' can be used to modify any and all parameters during the computation (see for example ''apps.remeshing2.fullAuto.cont2bRemeshing''). For example, if we want to double the mesh density after two remeshing, we simply add in the ''getParameters()'' function of the script (after the update !) : 
  
     if p['integrationNumber'] < 3:     if p['integrationNumber'] < 3:
Line 346: Line 350:
 Two different remeshing criteria have been implemented yet, one based on a ''[[doc/user/results/courbes_res#valueextractor|ValueExtractor]]'', the other on time. Two different remeshing criteria have been implemented yet, one based on a ''[[doc/user/results/courbes_res#valueextractor|ValueExtractor]]'', the other on time.
  
-Previously, the one relying on a valueExtractor was used in a very simple way : on one side of the part, with the field ''IF_MESH_QUALITY''. But is can be used with any ''[[doc/user/results/courbes_res#valueextractor|ValueExtractor]]'' you want, and on any geometrical entity. For example, let us assume that we want a criterion based on the aspect ratio, which is to be evaluated on two different sides. Then we simply define a skin with these two sides and we have the following :  +Previously, the one relying on a ''valueExtractor'' was used in a very simple way : on one side of the part, with the field ''IF_MESH_QUALITY''. But is can be used with any ''[[doc/user/results/courbes_res#valueextractor|ValueExtractor]]'' you want, and on any geometrical entity. For example, let us assume that we want a criterion based on the aspect ratio, which is to be evaluated on two different sides. Then we simply define a skin with these two sides and we have the following :  
  
     #Stop Criterion     #Stop Criterion
Line 359: Line 363:
  
 But then, there is also a simple criterion based on time, if you want to remesh every few seconds or so. But then, there is also a simple criterion based on time, if you want to remesh every few seconds or so.
-In this case, you must first define a vector containing all the times at which you want to remesh (''p[stopTime]''), then use the key ''p[integrationNumber]'' to set the right remeshing time depending on the integration. See below for the example : +In this case, you must first define a vector containing all the times at which you want to remesh (''p[stopTime]''), then use the key ''p[integrationNumber]'' to set the right remeshing time depending on the integration. See below, or see ''apps.remeshing2.fullAuto.cont2cRemeshing'', for the example : 
  
     def getParameters(_p={}):     def getParameters(_p={}):
Line 415: Line 419:
   CopyRemesher(side, p['remeshing'].oldDomain, domain, density).execute()   CopyRemesher(side, p['remeshing'].oldDomain, domain, density).execute()
  
-Therefore, if you have a complex domain, just divide it into the appropriate sides and copy/remesh as you see fit.  +Therefore, if you have a complex domain, just divide it into the appropriate sides and copy/remesh as you see fit. However, when you want to remesh one side, copy another side, and that the two sides have a common edge, then you must first use CopyRemesher, then Gen4remesher, in order ensure that the nodes of the edges are also copied and not regenerated !
- +
-<note> When you want to remesh one side, copy another side, and that the two sides have a common edge, then you must first use CopyRemesher, then Gen4remesher, in order ensure that the nodes of the edges are also copied and not regenerated ! </note>+
  
 ==== Transfinite Meshers ==== ==== Transfinite Meshers ====
  
-Sometimes, it is useful to first mesh curves using the [[doc:user:geometry:mesh:1d#SimpleMesher1D]] before meshing the domain itself, in order for example to ensure that some nodes are equidistant (not certain when using Gen4 alone). +Sometimes, it is useful to first mesh curves using the [[doc:user:geometry:mesh:1d#SimpleMesher1D]] before meshing the domain itself, in order for example to ensure that some nodes are equidistant (which is not certain when using Gen4 alone). However, at this point, it is not possible to use the SimpleMesher1D for remeshing (again, simply because I never had the use for it). Also, you cannot remesh using [[doc:user:geometry:mesh:2d#Transfinite mesher]], simply because I have been able to do all I want with Gen4 and did not take the time to program it. Feel free to do it if you want.  
 + 
 +You can, however, use transfinite meshers to define your first, initial mesh. This initial mesh can indeed be created using any configuration of meshers one can think of. However, reading the results afterwards is going to be annoying. 
  
-At this point, it is not possible to use the SimpleMesher1D for remeshing (again, simply because I never had the use for it). +For example, let us assume that TransfiniteMesher2D is used to create the first mesh. Then, for the first integration, no mesh files are saved, so to reload the corresponding facs the mesher must be executed again. 
 +For the others integrations, Gen4Remesher is used, and a mesh file is saved, so reloading the fac means reading the mesh file. 
  
-Also, you cannot remesh using [[doc:user:geometry:mesh:2d#Transfinite mesher]], simply because I have been able to do all I want with Gen4 and did not take the time to program it. Feel free to do it if you want. +However, when loading a fac, there is no way to know which operations should be done, executing the transfinite mesher or reading the gen4 mesh file. Consequently, the test-case will have to be slightly modified depending on the results you want to read. This is annoying indeed, and could be solve if mesh files were saved for any meshers. In would be interesting to do so, but well...
  
 ===== Data Transfer ===== ===== Data Transfer =====
Line 431: Line 436:
 By default, the transfer of data is done using Philippe's complex "FVTM" routine with all its default parameters (see [[doc:user:meshtransfer:datatransferbetweenmeshes]], in French). By default, the transfer of data is done using Philippe's complex "FVTM" routine with all its default parameters (see [[doc:user:meshtransfer:datatransferbetweenmeshes]], in French).
  
-For the advanced user, changing these parameters is possible (in the ''main()'' function of the [[#File 2 : script|script]])+For the __advanced__ user, changing these parameters is possible (in the ''main()'' function of the [[#File 2 : script|script]])
  
 ==== Changing the transfer method ==== ==== Changing the transfer method ====
Line 463: Line 468:
   cell.addOption(INTPT_NB, 5)   cell.addOption(INTPT_NB, 5)
    
-To understand all these options, please look at [[doc:user:meshtransfer:datatransferbetweenmeshes|Philippe's doc]]+To understand all these options, please look at [[doc:user:meshtransfer:datatransferbetweenmeshes|Philippe's doc]].
  
 ====  Changing the fields to transfer ==== ====  Changing the fields to transfer ====
  
-The list of fields which must be transferred is defined by default. If, amongst these fields, some are not to be transferred, this can be mentioned with the command ''addFieldToIgnore(field)''. For example :+The list of fields which must be transferred is defined by default. If, among these fields, some are not to be transferred, this can be mentioned with the command ''addFieldToIgnore(field)''. For example :
  
   autoRemesh = AutomaticRemeshing(getMetafor, __file__)   autoRemesh = AutomaticRemeshing(getMetafor, __file__)
Line 485: Line 490:
      
   autoRemesh.setInteractionToPostStep(101)   autoRemesh.setInteractionToPostStep(101)
 +  autoRemesh.setInteractionToPostStep(102)
  
-will recompute all contact properties on the interaction 101.+will recompute all contact properties on the interaction 101 and 102.
 ===== Balancing ===== ===== Balancing =====
  
Line 518: Line 524:
 $\boldsymbol{F}^{int}=\boldsymbol{F}^{ext}$ $\boldsymbol{F}^{int}=\boldsymbol{F}^{ext}$
  
-After remeshing and data transfer, this equation is no longer true, so we have (where the $\boldsymbol{F}_t$ means force after transfer)+After remeshing and data transfer, this equation is no longer true, so we have (where the index $t$ in $\boldsymbol{F}_t$ means that we consider the value after transfer)
  
 $\boldsymbol{F}^{unbal} = \boldsymbol{F}^{int}_t - \boldsymbol{F}^{ext}_t$ $\boldsymbol{F}^{unbal} = \boldsymbol{F}^{int}_t - \boldsymbol{F}^{ext}_t$
  
-The post-remeshing algorithm is simply a variation of the quasi-static integration scheme where this imbalance is to be solved. First, we simply try to solve the equation as it is. If it works, then the imbalance is corrected and the real integration can start again. If it does not work, then an increasing fraction of the unbalanced forces are applied as external forces, in order to solve the imbalance little by little. +The post-remeshing algorithm is simply a variation of the quasi-static integration scheme where this imbalance is to be solved. First, we simply try to solve the equation as it is. If it works, then the imbalance is corrected and the real integration can start again. If it does not work, then an increasing fraction of the unbalanced forces are applied as external forces, in order to solve the imbalance little by little. Once verified for a given fraction, the the unbalanced forces are recomputed and the algorithm started again, until equilibrium is restored. 
  
 Mathematically, we are therefore trying to solve for $\boldsymbol{F}^{int}$ the equation :  Mathematically, we are therefore trying to solve for $\boldsymbol{F}^{int}$ the equation : 
Line 538: Line 544:
 $$ = (1-\alpha_F) \boldsymbol{F}^{\text{ext}}(t^{n+1}) + \alpha_F \boldsymbol{F}^{\text{ext}}(t^n)$$ $$ = (1-\alpha_F) \boldsymbol{F}^{\text{ext}}(t^{n+1}) + \alpha_F \boldsymbol{F}^{\text{ext}}(t^n)$$
  
-The idea is similar : after remeshing, there is some imbalance and the equation is no longer verified, so we want to apply a balancing algorithm to restore equilibrium before restarting the computation. Since the time is stopped, inertial forces are kept as they are and only internal forces are modified to satisfy equilibrium. In the same way as for a quasi-static simulation, this is done by applying as external forces an increasing fraction of the unbalanced forces. +The idea is similar : after remeshing, there is some imbalance and the equation is no longer verified, so we want to apply a balancing algorithm to restore equilibrium before restarting the computation. Since the time is stopped, inertial forces are kept as they are and only internal forces are modified to satisfy equilibrium. In the same way as for a quasi-static simulation, this is done by applying as external forces an increasing fraction of the unbalanced forces. The difference with respect to the quasi-static algorithm is the expression of the unbalanced forces, which will here also contains the inertial forces and the forces computed at the previous time step.
  
 Since we conserve the inertial forces and correct the internal ones, this post-remeshing algorithm works quite well for quasi-static and low speed dynamic computations. For high speed dynamic computations, it is best not to use it and simply let the simulation continue. Since we conserve the inertial forces and correct the internal ones, this post-remeshing algorithm works quite well for quasi-static and low speed dynamic computations. For high speed dynamic computations, it is best not to use it and simply let the simulation continue.
 +
 +==== Options ====
 +
 +The complete ''setBalancing'' command is actually
 +
 +  setBalancing(executeBalancing, velocitiesExtrapolation=True, maxItes=7, balancingTolerance=0.001)
 +  
 +The first argument has already been described and indicates whether balancing should be done or not. 
 +
 +For the advanced user, a few options can be played with by changing the three of arguments. 
 +
 +First of all, it is possible to deactivate the ''stepPredictor()''. If you do not know what it is, do not touch it. If you do, well sometimes, when transfer errors are significant, the balancing can go better if executed without this predictor, so without extrapolating the next step based on velocities and accelerations. This is fine only in quasi-static, because in dynamic computations velocities and accelerations also intervene in the computation of forces. To do so, simply set the second argument to ''False''. If have not investigated this greatly, but I believe that this could be a sign that the mesh of the computation was not fine enough, so activating this option could hide the real problem. I believe it should be reserved for battery tests, because we want to have tests with rather coarse meshes there. 
 +
 +Second, the number of iterations for each step of the balancing can be changed. By default, seven iterations are tried before increasing the fraction of the unbalanced forces and starting again.
 +
 +Finally, the tolerance can also be changed. The parameter $\alpha$, used to ponder the unbalanced forces, starts at 1 and is progressively divided by 2 when a step fails. Once $\alpha$ becomes smaller than the tolerance, the algo stops itself, returns an error, and the temporal integrationdoes not restart. The default value of 0.001 can be changed if needed. 
 +
 + --- //[[pjoris@ulg.ac.be|Pierre Joris]] 2016/06/13 //
doc/user/remeshing/remeshing.txt · Last modified: 2018/05/04 15:47 by boman
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki