"ERROR: Zone does not have a property hash" and odd inconsistent behaviour when running 2 zones

[Leonard Nielsen]

Dear Professor Meyer,

I'm modifying a code (same basic structure as run_single_zone, but very heavily modified) to run two zones at the same time for the purpose of exchanging radiation between them. However, it's behaving oddly and incosistently - I get semi-random numerical breakdowns at some times (I seem to get zero elements in vectors that shouldn't have them), and at others, error message like that in the title. My approach to modifying the code to run both in a sequence was simply to turn the zone and pointers (p_my_output, p_my_nucnet) into an array with two elements. Initializing and loading properties using get_nucnet(), getProperty, updateProperty, setZoneCompareFunction, create_network_copy and whatnot seems to basically work okay. When the calculations do work, I usually get the "property hash" error, and I'm not quite clear on what that is due to. The calculations never work past the first timestep.

My educated guess is that there is a memory issue somewhere, but what I don't know is if it's because of something I've implemented (which includes Fortran subroutines handling 2D arrays, which I'd otherwise expect to be the source of this type of issue, but it doesn't look like it), or if it's something I'm overlooking in Libnucnet. So, in order for me to figure out what is going on, it would be very helpful for me to know: what exactly is the "property hash", and are there any limitations to running zones in sequence I may have forgotten - e.g. some function I need to run every time I switch from one to the other? Apart from the network calculations, zones, and input-output functions, I also use some libnucnet functions to calculate Q-numbers, average nuclear mass number, and the like, but nothing particularly strange.

Thank you!

Regards,
Leonard

[Bradley S. Meyer]

Hi Leonard,

Thanks for this interesting post. I put the check on the property hash in to catch zones that hadn't been properly initialized--something I obviously did in the past. That may be the issue here. Another issue here is that the underlying libxml defines globals, so one has to be careful with parallelization.

I think what you are trying to do is what I call a multi-zone calculation. There is a version of that, but let me work on something that might be closer to what you had in mind. So I am clear, you'd like to run a timestep in two zones, have the zones interact via their zones properties (say, exchange "heat"), and run another timestep. Is that correct? Let me know.

Best wishes.

[Leonard Nielsen]

So I am clear, you'd like to run a timestep in two zones, have the zones interact via their zones properties (say, exchange "heat"), and run another timestep. Is that correct? Let me know.

Yes, exactly!

Thank you!

[Bradley S. Meyer]

Hi Leonard,

I see I didn't actually answer your question about the property hash. It is the libxml hash that carriers the zone properties (the optional properties). If you create zones, you need to be sure to give them a network and a name with Libnucnet__Zone__new(). For example, something like the following should work:

#include <Libnucnet.h>
#include <boost/lexical_cast.hpp>

// main(), etc.

Libnucnet__Net * p_net = Libnucnet__Net__new_from_xml( "network.xml", "", "" );

std::vector<Libnucnet__Zone *> p_zones;

for( i = 0; i <= 10; i++ )
{
  std::string s_zone = boost::lexical_cast<std::string>( i );
  p_zones.push_back(
    Libnucnet__Zone__new( p_new, s_zone.c_str(), NULL, NULL )
  );
}

for( i = 0; i <= p_zones.size(); i++ )
{
   Libnucnet__Zone__updateProperty(p_zones[i], "t9", NULL, NULL, "1.0" );
 }

for( i = 0; i <= p_zones.size(); i++ )
{
    std::cout << i << "  " << Libnucnet__Zone__getProperty(p_zones[i], "t9", NULL, NULL ) << std::endl;
}

// Exit, etc.

Of course NucNet Tools wrappers will make this easier--which is what I will work on (as mentioned in the earlier post).

[Leonard Nielsen]

Thanks a lot, I will try and implement this!

[Bradley S. Meyer]

Ok. I should have noted that one should also free the memory for the zones:

for( i = 0; i <= p_zones.size(); i++ )
 {
     Libnucnet__Zone__free( p_zones[i] );
  }

when finished. If you add the zones to a Libnucnet structure p_my_nucnet, then

 Libnucnet__free( p_my_nucnet );

will free the zones automatically.

[Leonard Nielsen]

OK, I have gone over all of my scripts and made them compatible with the various libnucnet pointer objects (well, structures, I guess the term is, but anyway, essentially cutting out much of NNT* - a bit painful and very tedious, but hey, as long as it works). Everything compiles, I just need to understand how to use my LibnucnetZone and LibnucnetNet objects. How do I write to my Zone object from my Zone XML? The standard functions seem to want Libnucnet, not Libnucnet__Zone objects (I take it that the "Libnucnet" object is some kind of link between Nets and Zones?). Similarly, how do I get output from a Zone XML in the most painless way?

Thanks a lot for the help!

*Not strictly necessary, but since at this point I only really rely on Libnucnet for input/output, the actual evolution of the network, and extracting statistics on the abundances and abundance changes, it's just more convenient at this point to work directly with the pointers and C libraries.

[Leonard Nielsen]

OK, I got it all worked out now, it seems!

[Bradley S. Meyer]

Thanks for letting me know. I haven't had time to try my multi-zone version of what you are after. In any event, libnucnet is a stand alone library (apart from its dependencies) relative to NucNet Tools. NucNet Tools is a set of convenience C++ code that wraps libnucnet. It sounds like you'd do well to work just with libnucnet. Remember there are a lot of examples to help with understanding the library. As I can, I will still pursue my version of what you are after, but it may not be for several weeks. Let me know if you have other issues or questions, but for now, I'll consider this closed. Best wishes.