Hack to delete particles

MFIX-Exa Help
#1

Hey,
Working on stuff for the granular doc… I’ve been using @RobertoPorcu’s hack to move particles in src/des/mfix_pc_updates_K.H with something like:

  if (p_realarray[SoArealData::radius][i] < 2.99e-3 ) {
    p_velx_new = p_velx_old;
    p_vely_new = p_vely_old;
    p_velz_new = p_velz_old;
    //
    p_omegax_new = p_omegax_old;
    p_omegay_new = p_omegay_old;
    p_omegaz_new = p_omegaz_old;
  }

Now, I want to do the case of Zhou et al, Physica A, 269 (1999). Can I make the particles just “vanish?”

#2

If you set particle.id() = -1, that particle should “vanish” the next time a “particles redistribute” operation is called

#3

Thanks, Roberto, I’ll try that

#4

Sounds good. If you want to have an example, you can find a few calls to p.id() = -1 into des/mfix_pc_remove_out_of_range.cpp

#5

That gave me the compiler error

/nfs/scr/2/wfullmer/granular/mfix/src/des/mfix_pc_updates_K.H:93:7: error: ?particle? was not declared in this scope
   93 |       particle.id() = -1;
      |       ^~~~~~~~
#6

ah, p.id() = -1 compiles, let me run my test…

#7

yeah, sorry about that. I wrote particle meaning any variable name you have in your function that refers to a amrex::Particle object.
Do you have anything like this :point_down: in your code?
auto p = pstruct[p_id];

#8

idk Roberto, it’s your code, I’m just butchering it. but that worked. I put a fake particle in so I could count once per dem dt and the side supports were deleted after an initial settling period like I wanted. thanks!

#9

ta da

#10

Can you share the inputs you used for this?

#11

Hi @Doug, welcome to the forum.

The answer is yes, but many caveats.

  • if you have previous experience with MFiX, this is not it. This is MFIX-Exa, please note these words of caution
  • currently, the latest released version is 12.06, so you can’t just compile that file into the code, you will have to pick out my (truly ugly) hacks which are all commented by //wdf
  • this gets called every dem time step for every particle, so I have a “fake” particle under the initial bed that is just used to index. if you really want to do something like this for a real problem, you should consult with us on how to incorporate time or time step
  • the tan_history and rolling_friction inputs are developmental, they aren’t in the code yet
  • source_pgen.f90 is my little particle generator, this is not part of MFIX-Exa, just a crude way to generate the particle_input.dat files I want
  • inputs_full make the animation above with the ascent_actions.yaml file; inputs shifts the domain up a little bit to cut the csg geometry so that the particles spill out of a pressure outlet and are deleted rather than forming a static pile
1 Like
#12

oops, and here are the files
static_pile.zip (9.0 KB)

#13

I was able to build the code following the ubuntu instructions on this forum using the code that I downloaded from the mfix.netl.doe.gov website. This all worked on linux mint except boost, but 1.87 seemed to work. I was able to build the code and include your //wdf additions. When I run the code, I get the below error message. It appears that you did not provide the geometry file.

ERROR: Cannot open file static-pile_Zhouetal.csg
terminate called after throwing an instance of ‘csg::Exception’
what(): Exception Data:
Source : read_csg
Message : ERROR: Cannot open file static-pile_Zhouetal.csg

#14

Yep, my bad. It’s attached here:
static-pile_Zhouetal.csg (311 Bytes)

#15

Thanks. I can now run it. I see the monitor output. But there are errors,
“Error saving PNG buffer to file: ./pngs/vis_p_rp_000000.png”
I found that I needed to use an absolute path in image_prefix in the ascent_actions.yaml file. Now it runs without errors and creates the vis_p_rp_******.png images. But the particles do not fall like in your video. They just hover for the entire simulation. I did see the print statement in the mfix_pc_updates_K.H file. I commented it in, remade the code, and it looks like l_counter is always zero. That means the 208000 is condition is never reached and the grey particles are never deleted. But I do not know why.

#16

@Doug

  1. Yeah, sorry about that… I forgot to say to mkdir pngs in your run directory that way all the pngs print to a single subdir and don’t clutter your run directory. You can use local or absolute path names in the yaml file.
  2. As I said above, if you run the inputs_full case you should be able to get the same result as I posted.
  3. There is a mistake in my other setup. I’ve clipped the bottom of the domain off, so the “fake” particle I’m using to count gets removed before it starts to run. You can move the last particle to somewhere in the domain by either adjusting the particle generation script or just directly in the last line of the generated particle_input.dat file. But, I have to say, this whole case is all very hacky and not a good place to start learning MFIX-Exa. Do you have a problem of interest that we could maybe suggest something that’s more relevant to start from?