Fluids

Fluids

Topics related to Fluent, CFX, Turbogrid and more.

Fluid velocity in dpm_drag

    • Chris_g
      Subscriber

      Hi,

      to implement a custom drag model I need to calculate the difference in velocity between fluid and particle. Getting the particle velocity is no problem however the fluid velocity is causing me trouble. I am trying to access it using the following UDF:

       #include "udf.h"
       #include "surf.h"
       #include "dpm_types.h"
       #include "dpm.h"
       #include "dpm_mem.h"
       #include "mem.h"
       #include "materials.h"
       #include "threads.h"

      DEFINE_DPM_DRAG (test_drag, Re, tp)
      {
          cell_t c;
          Thread *t0;
          real uvel;
          
          t0 = TP_CELL_THREAD(tp);
          c = TP_CELL(tp);
          
          uvel = C_U(c,t0);

      }

      When executing this UDF I am getting the following error:

      ==============================================================================

       

      Node 0: Process 2364: Received signal SIGSEGV.

       

      ==============================================================================

       

      999999: mpt_accept: error: accept failed: No error

       

      Can you help me, what am I doing wrong?

       

      Thank you!

      Chris

    • Rob
      Forum Moderator

      What are you returning to Fluent? The above looks sensible according to a colleague. 

    • Chris_g
      Subscriber

      Thanks for your quick reply. Currently I am using a dummy:

      real drag_force = 0.0;

      return (drag_force);

    • Rob
      Forum Moderator

      Try with 0.1  zero's in unexpected places can cause problems. 

    • Chris_g
      Subscriber

      I just tried that, unfortunately it didn't solve the problem

    • Chris_g
      Subscriber

      I just tried the UDF on a different machine and it works, so the problem seems to be with the fluent installation. Version was 21R2 on both machines.

    • Rob
      Forum Moderator

      I'm not going to check the whole code, but if you post the main bits we can have a quick look. Other community members aren't under the same restrictions. 

    • Chris_g
      Subscriber

      I am testing on a MWE so this is the whole code:

       #include "udf.h"
       #include "surf.h"
       #include "dpm_types.h"
       #include "dpm.h"
       #include "dpm_mem.h"
       #include "mem.h"
       #include "materials.h"
       #include "threads.h"
       
       
      DEFINE_DPM_DRAG (test_drag, Re, tp)
      {
          cell_t c;
          Thread *t0;
          real uvel;
          
          t0 = TP_CELL_THREAD(tp);
          c = TP_CELL(tp);
          
          uvel = C_U(c,t0);
          
          real drag_force;
          drag_force = 0.1;
               
          return (drag_force);
      }

    • Rob
      Forum Moderator

      Both with the same OS? Did you compile the code on both?  Fluent shouldn't fail like that, if solver failed to launch it's the installation, in theory cases & UDFs can't be machine dependent. 

    • Chris_g
      Subscriber

      The working machine is a RedHat 8.7 compiled with the system compiler (as built-in is not available on linux).

      The other machine is a Windows 10 using built-in compiler. On this machine I also occasionally get an error 126, which is solved after logging off and on again on the PC (I don't know if this is related).

    • Rob
      Forum Moderator

      The 126 error seems to be when old UDF code is missing, a few of my test cases have this as they've been altered a few times since creation in Fluent 5-6. 

      Did the code compile without errors or warnings on Win10? Did you then load that libudf and check the hooks were present?

    • Chris_g
      Subscriber

      The 126 doesn't seem to be related to the UDF, since it only appears sometimes but not always when using the same UDF. Compilation works fine, the error 126 occurs on loading of the UDF.

      When the 126 doesn't occur, compilation and loading works fine, hook is set for one injection. If the hook is not set, the "999999: mpt_accept: error: accept failed: No error" does not appear, as expected.

    • Rob
      Forum Moderator

      I wonder if the case corrupted somehow. It shouldn't, but I can't see what else is causing this. Going Win10 to Linux occasionally causes problems if you leave whitespace characters in the .c file, I don't think that can happen coming the other way. 

    • Chris_g
      Subscriber

      After some more testing, the problem occurs on both machines, just the handling is slightly different:

      On Windows 10 built-in compiler the error occurs directly at this line: uvel = C_U(c,t0);

      On RedHat system compiler that line is executed but when I try do anything with this value (calculations, output using Message("u %g", uvel); or saving C_UDMI(c,t0,0)=uvel; ) fluent throws an error. I assume uvel just contains a "garbage" value after using C_U(c,t0); however I haven't found a way to check. Outputting other known values or saving to UDMI using the syntax above works fine.

    • Rob
      Forum Moderator

      I wonder if the cell isn't passed to the macro,  https://ansyshelp.ansys.com/account/Secured?returnurl=/Views/Secured/corp/v231/en/flu_udf/flu_udf_DPMDEFINE.html  Example 2.5.6.3 suggests you may need to tell the UDF about the cell, and thread: look for  cell = PP_CELL(p)   That may not fix the problem, but may get you a bit further.

      Once you get it working please post the structure for others. 

    • Chris_g
      Subscriber

       

      Using PP_CELL or TP_CELL doesn’t make a difference.I am not sure I understand the difference correctly but from my understanding TP_ should be correct.

      I agree, the link the cell is likely the problem. I tested if "cell = TP_CELL(p)" works by outputting "Message(“cellid %d”, cell);" and it looks plausible (values between 0 and my max cell count). For the thread "t0 = TP_CELL_THREAD(tp)" I first checked "if (NULLP(t0)) Message(“Nullpointer”);" and it did not trigger. However "if (NULLP(THREAD_STORAGE(t0,SV_U))) Message(“Nullpointer”);" triggers. From my understanding this should be the location were C_U(c,t) looks for the data.

      So I am wondering, if I am referencing a Thread but not the correct one? Or is the storage location wrong? Do I need to account for any Subthreads? I have one Eulerian Phase and one DPM phase in my case.

       

    • Rob
      Forum Moderator

      Are you using the Eulerian multiphase model? Or single phase plus DPM? It's a terminology problem, and one that's fairly common. 

    • Chris_g
      Subscriber

       

      I am using 1 Eulerian phase and 1 Discrete Phase DDPM 4-way coupled (no DEM collisions)

       

    • Rob
      Forum Moderator

      Ah, that may explain the problems. With the Eulerian model you need to account for the phase domain too: remember each phase has it's own momentum equations. 

    • Chris_g
      Subscriber

      I was not aware that you could use DPM without an Eulerian phase. I now tried:

      Domain *gas_domain;

      gas_domain = Get_Domain(2); //Domain ID from multiphase interface

      Thread *T0 = Lookup_Thread(gas_domain, 56); //56 from boundary condition Zone-ID for internal Zone

      cell_t c = TP_CELL(tp);

      real uvel = C_U(c,t0);

      This doesn't work, but I am not sure at all if this correct.

       

      However in the meantime I found a work-around that seems to work:

      cphase_state_t *cell = *(&(tp->cphase));

      real uvel = cell->V[1];

      In a short test this seems to give plausible values. There is no documentation for this function (I found it in the dpm_types.h file) so it would be nice if you could confirm, that those are the values for the fluid phase. If so I should be able to get all my required values this way.

       

      So in the end while it is still interesting what is wrong with my original approach, right now it seems like the problem is solved for me.

      Thanks for your help!

    • Rob
      Forum Moderator

      The phase thread stuff is here   https://ansyshelp.ansys.com/account/Secured?returnurl=/Views/Secured/corp/v231/en/flu_udf/flu_udf_GenPurposeLoopingMacros.html%23flu_udf_sec_THREAD_SUB_THREADS  (scroll up a bit).

      I can't comment on the undocumented macros. However, you may want to check the way C counts as real uvel = cell->V[1]   may be looking at the vvel! C count 0, 1, 2 etc so directions are x=0, y=1 and z=2.  

       

      The Eulerian multiphase model is for more highly packed particles/bubbles/droplets. DPM is good to about 10-14% volume fraction. The latter is computationally cheaper, and works in a different way. 

    • Chris_g
      Subscriber

       

      I definitely need the Eulerian model (with DDPM phase) since my volume fraction is far beyond 15%.

      I read through the guide again also section 1.9.1 and from my understanding I have 3 domains: mixture (ID 1), eulerian (gas) phase (ID 2, phase_domain_index 0), dpm phase (ID 3, phase_domain_index 1). TP_CELL_THREAD(tp) probably returns the Thread from domain 3 (DPM) so I need to first get a pointer to the mixture domain and then to the gas domain to read the gas velocity. I have tried that with the code below, but this still throws the error.

      real uvel;

      cell_t c;

      c = TP_CELL(tp);

      Thread *pthread, *gthread, *mixthread;

      pthread = TP_CELL_THREAD(tp); //get particle thread

      mixthread = THREAD_SUPER_THREAD(pthread); //get mixture thread

      gthread = THREAD_SUB_THREAD(mixthread,0); //get gas phase thread; phase_domain_index of gas phase is 0

      uvel = C_U(c,gthread);

       

    • Rob
      Forum Moderator

      OK. Not sure, I've run Eulerian models with UDFs but not DPM. Not sure what else I can suggest within the Community rules.

      What are you modelling?

    • Chris_g
      Subscriber

      So I think I got it working now. Apparently TP_CELL_THREAD returns the mixture thread, not the particle thread. I don't understand why that is the case and in my opinion the UDF guide says otherwise (Table 3.29), but it doesn't crash and gives me plausible values.

      My code is now (declarations as above):

      mixthread = TP_CELL_THREAD(tp);
      gthread = THREAD_SUB_THREAD(mixthread,0);

      c = TP_CELL(tp);

      urel = C_U(c,gthread);

    • Rob
      Forum Moderator

      Thanks for adding a solution. I'll talk to the developer about some more UDF examples as we've seen a few DPM/DDPM thread problems in the last few weeks. 

Viewing 24 reply threads
  • The topic ‘Fluid velocity in dpm_drag’ is closed to new replies.