ceed - replace usage of ceed->op_fallback_parent with ceed->parent

[zatkins-dev]

The ceed->op_fallback_parent member is redundant and creates potential data mismatches between a given Ceed context and its children. This removes the need to manually copy over JiT source roots and defines from the parent to fallback Ceed and prevents possible footguns when using the Ceed*Parent* interfaces.

[jeremylt]

The parent and fallback parent are different logically though

[zatkins-dev]

Are they though? Both of them refer to the Ceed context that created it, and I don't think there's a situation where a single Ceed context can be both a delegate and a fallback.

[jeremylt]

They are different logically. If we need both is a different question

[zatkins-dev]

Okay. I think that in a fallback Ceed, when I call CeedGetParent, I would expect it to return the Ceed that was responsible for creating it. I would also expect it to inherit the JiT defines and such automatically, so that you don't have to somehow update the JiT defines separately on the fallback operator's Ceed if I change something on the parent.

[zatkins-dev]

So perhaps they are logically distinct, but abstractly I think they serve the same role

[jeremylt]

Thinking it over, I'm sold.

Ok, so other question here then - creating a Ceed object is cheap, should we just create the fallback Ceed itself instead of creating the string? (Then we could set the fallback Ceed and delegate Ceed and the same Ceed in some cases so would need to make sure the logic plays out correctly)

[zatkins-dev]

Hmm that seems reasonable, since then parent would be the same anyway. To me, fallback is essentially a weak delegate. In fact, I feel like we could probably replace most instances of CeedOperatorGetFallback with CeedGetObjectDelegate("Operator", ...) and have things work fine. I'd have to test it though.

I understand if that's mixing different logical components too much though.

[jeremylt]

I am not sure that the delegate will work. A delegate is designed to fully replace the full object functionally.

[zatkins-dev]

Okay, I just updated to make the operator fallback interface more like the delegate interface, lmk what you think

[jeremylt]

We should make sure all the JiT paths are copied over as needed

[jeremylt]

Really, Ratel running correctly with this branch for GPU would verify the changes

[zatkins-dev]

The JiT paths no longer need to be copied at all, since, the JiT paths come from the parent. I've been running Ratel with this all day, so I think it's good!

[jeremylt]

Cool, my only quibble now is that the developer documentation needs to be updated to reflect this

https://github.com/CEED/libCEED/blob/main/doc%2Fsphinx%2Fsource%2FlibCEEDdev.md

[jeremylt]

Thanks for this update