Document that array creation must occur on PE0
ckNew calls are restricted to PE0 since the 64-bit ID changes were integrated. Document this restriction in the array basics section of the manual. There's also a newly added API to call for array creation asynchronously, with the resulting array ID delivered through a callback. Document that in the intermediate/advanced section, and reference it from the earlier section.
#3 Updated by Phil Miller over 2 years ago
- Target version deleted (
- Status changed from Feedback to Rejected
- translation missing: en.field_closed_date set to 2017-02-21 12:18:12.593167
Unless we hear otherwise, this wasn't actually a problem that was occurring. Something else was conflated with this effect, probably.
#4 Updated by Jozsef Bakosi over 2 years ago
I finally got around to reproduce this problem with the attached minimal example. This mimics what I'm trying to do: from a driver chare, create an empty array and a group and from the group use insert() to add array entries. Note insert.C:34. If the driver chare is created on PE 0 all is well in both serial and parallel. However, change the Driver chare's PE to, e.g., 1, and run on two PEs and the following assert is generated:
 Assertion "CkMyPe() == 0" failed in file ckarray.C line 780.
I don't know if this is a behavior that would be incompatible with design/usability requirements, but this example does reproduce a behavior that was previously correct. Also, even if this is important for you guys to keep it this this way, i.e., array::ckNew() must always be called from PE 0, it is okay, because it appears that there is a simple fix: ensure that the driver is always created on PE 0.
#5 Updated by Phil Miller over 2 years ago
- Subject changed from Dynamic array insertion fails when insert() is not called from PE 0 to Document that array creation must occur on PE0
- Target version set to 6.8.0
- Assignee changed from Phil Miller to PPL
- Status changed from Rejected to New
- Description updated (diff)
Indeed, this is intended behavior, that does limit usage that was previously allowed. As you note, there's a fairly easy workaround. We need to document this in the manual, as well as the asynchronous interface that lets the array creation call come from any PE, but returns the resulting ID through a callback