Compile with CustomFunc(Particles) in Debug Mode

[S-Explorer]

Hi

When using IAMR, I wrote a set of particle processing methods through the particle module of amrex. When compiling, I encountered the following problem: in the GNUmakefile, USE_PARTICLES = TRUE is enabled, but the original particle part in IAMR will also be activated accordingly. However, if I do use USE_PARTICLES = FALSE and instead only include $(AMREX_HOME)/Src/Particle/Make.package, it can compile successfully in Release mode, but encounters compilation errors in DEBUG mode. Here is a partial compilation error message.

../../../amrex/Src/Particle/AMReX_ParticleUtil.H:32:44: error: ‘IsParticleIterator’ was not declared in this scope; did you mean ‘IsMultiFabIterator’?
   32 | template <class Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value, int> foo = 0>
      |                                            ^~~~~~~~~~~~~~~~~~
      |                                            IsMultiFabIterator
../../../amrex/Src/Particle/AMReX_ParticleUtil.H:32:71: error: template argument 1 is invalid
   32 | plate <class Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value, int> foo = 0>
      |                                                                    ^

../../../amrex/Src/Particle/AMReX_ParticleUtil.H:32:86: error: ‘foo’ does not name a type
   32 |  Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value, int> foo = 0>
      |                                                                       ^~~

Compiling hydro_compute_edgestate_and_flux.cpp ...
../../../amrex/Src/Particle/AMReX_ParticleUtil.H:50:44: error: ‘IsParticleIterator’ was not declared in this scope; did you mean ‘IsMultiFabIterator’?
   50 | template <class Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value && !Iterator::ContainerType::ParticleType::is_soa_particle, int> foo = 0>
      |                                            ^~~~~~~~~~~~~~~~~~
      |                                            IsMultiFabIterator
../../../amrex/Src/Particle/AMReX_ParticleUtil.H:50:71: error: template argument 1 is invalid
   50 | plate <class Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value && !Iterator::ContainerType::ParticleType::is_soa_particle, int> foo = 0>
      |                                                                    ^

../../../amrex/Src/Particle/AMReX_ParticleUtil.H:50:80: error: expected ‘>’ before ‘&&’ token
   50 | ass Iterator, std::enable_if_t<IsParticleIterator<Iterator>::value && !Iterator::ContainerType::ParticleType::is_soa_particle, int> foo = 0>
      |                                                                    ^~

../../../amrex/Src/Particle/AMReX_ParticleUtil.H:50:145: error: ‘foo’ does not name a type
   50 | alue && !Iterator::ContainerType::ParticleType::is_soa_particle, int> foo = 0>
      |                                                                       ^~~

I hope to have more flexibility here by enabling the particle calculation part in IAMR through the addition of other macro compilation conditions, such as -DIAMR_PARTICLE, instead of it being activated simply by setting USE_PARTICLES = TRUE.

[WeiqunZhang]

There is a runtime parameter particles.do_nspc_particles in IAMR. I think it is meant to disable tracer particles at runtime. But it looks like there are some issues. If we fix that, would that work for you?

[WeiqunZhang]

The merge of #156 will close this issue. If it does not resolve the issue, please reopen it.

[ruohai0925]

@WeiqunZhang and @cgilet Following the previous PR opened by @S-Explorer, I think what we want is to add our particle-related subroutines and use them associated with IAMR. To use our particle-related subroutines, we need to set

USE_PARTICLES = TRUE

in the GNUMakefile. However, this will activate all the internal IAMR particle subroutines. Even after the above modifications, I still think some internal IAMR particle subroutines are automatically being used if USE_PARTICLES = TRUE. For example,

ifdef AMREX_PARTICLES

read_particle_params ();

endif

in the NSBase.cpp. That is not what we want.

Maybe we can change the AMREX_PARTICLES macro into sth like IAMR_PARTICLES to control the internal IAMR particle subroutines. We can then add sth like EXT_IAMR_PARTICLES to control the external/user-defined particle-related subroutines.

What do you think?

[WeiqunZhang]

The firs three lines of read_particle_params are

    ParmParse ppp("particles");
    ppp.query("do_nspc_particles", do_nspc);
    if (!do_nspc) return;

This is actually what we want. Do you have other examples of "some internal IAMR particle subroutines are automatically being used if USE_PARTICLES = TRUE"?

[S-Explorer]

Hi, @WeiqunZhang. Thank you very much for your response and the solutions you have provided.

As @ruohai0925 mentioned, we hope to have more freedom to control the program interface, so we aim to control the program compilation through macros.

in this file $(IAMR_HOME)/Exec/Make.IAMR, add this macros as follow:

if($(USE_IAMR_PARTICLES), TRUE)
    DEFINES += -DIAMR_PARTICLE
endif

By doing so, adding the following variable in the GNUmakefile will enable the macro definition:

USE_IAMR_PARTICLES = TRUE

In the end, by just replacing #ifdef AMREX_PARTICLES with #ifdef IAMR_PARTICLE in the source code, we may be able to achieve the desired effect. This was our initial idea. Would you think this approach could work?

#ifdef AMREX_PARTICLES
    //iamr particle calc
#endif

//The result after the replacement is as follows.
#ifdef IAMR_PARTICLE
    //iamr particle calc
#endif

I think that this method would potentially enhance the flexibility of the exposed interface, making it easier to extend the code.

[WeiqunZhang]

I am not saying what you are suggesting will not work for you. However, it's a breaking change for other codes like PeleLM that depend on IAMR source. They would need to modify their make system if we do what you are suggesting. So unless the run time parameter approach does not work for you, I don't think we want to make the macro change. Could you explain why the macro approach is more flexible? Could you show me why the run time parameter will not work for you? In fact one might argue the run time approach is more flexible because you only need to compile once and can use with or without particles.

[ruohai0925]

Got it! Thanks, Weiqun. Let us test the codes by using the run-time parameter.