Support additional `CeedContextFieldType` values

[zatkins-dev]

Summary

Add new enum values to CeedContextFieldType for single-precision floating point, 64-bit integer, byte, and CeedInt and CeedScalar types.

Possible Implementation

• Expand the CeedContextFieldType interface to include:

typedef enum {
  /// Byte value, C type of char
  CEED_CONTEXT_FIELD_BYTE = 1,
  /// CeedScalar value
  CEED_CONTEXT_FIELD_SCALAR = 2,
  /// Single precision value
  CEED_CONTEXT_FIELD_FLOAT = 3,
  /// Double precision value
  CEED_CONTEXT_FIELD_DOUBLE = 4,
  /// CeedInt value
  CEED_CONTEXT_FIELD_INT = 5,
  /// 32 bit integer value
  CEED_CONTEXT_FIELD_INT32 = 6,
  /// 64 bit integer value
  CEED_CONTEXT_FIELD_INT64 = 7,
  /// Boolean value
  CEED_CONTEXT_FIELD_BOOL = 8,
} CeedContextFieldType;

• Add strings/update indices in CeedContextFieldTypes.

• Add associated public registration functions:

int CeedQFunctionContextRegisterByte(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterScalar(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterFloat(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterInt(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterInt64(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);

• Add the associated public Get[TYPE]Read/Restore[TYPE]Read/Set[TYPE] functions (byte used as an example):

int CeedOperatorGetContextByteRead(CeedOperator op, CeedContextFieldLabel field_label, size_t *num_values, const char **values);
int CeedOperatorRestoreContextByteRead(CeedOperator op, CeedContextFieldLabel field_label, size_t *num_values, const char **values);
int CeedOperatorSetContextByte(CeedOperator op, CeedContextFieldLabel field_label, char *values);
int CeedQFunctionContextGetByteRead(CeedQFunctionContext ctx, CeedContextFieldLabel field_label, size_t *num_values, const char **values);
int CeedQFunctionContextRestoreByteRead(CeedQFunctionContext ctx, CeedContextFieldLabel field_label, const char **values);
int CeedQFunctionContextSetByte(CeedQFunctionContext ctx, CeedContextFieldLabel field_label, char *values);

• Update CeedQFunctionContextRegisterGeneric, CeedQFunctionContextGetGenericRead.

• Regenerate Julia bindings.

• Add new values to tests/t407-qfunction.

[ksd-2005]

Hi,
I am new to open source and have experience working with C/C++, OpenMP and CUDA, MPI.
I'd like to work on this.

but before I start , I have a few questions:

1. Does the proposed numbering intentionally change the values of the existing enumerators?
   Because in the /include/ceed/types.h the enum is

typedef enum {
  /// Double precision value
  CEED_CONTEXT_FIELD_DOUBLE = 1,
  /// 32 bit integer value
  CEED_CONTEXT_FIELD_INT32 = 2,
  /// Boolean value
  CEED_CONTEXT_FIELD_BOOL = 3,
} CeedContextFieldType;

If so that's an ABI break, and I'd rather append the new types unless you want the renumbering.

2.Also when i was reading the ceed-f64.h and ceed-f32.h files I realised the following:
CeedScalar is float or double depending on whether the build uses ceed-f32.h or ceed-f64.h, so a field registered as SCALAR and one registered as DOUBLE describe the same memory in an FP64 build.
Should CeedQFunctionContextRegisterScalar resolve to the concrete type at registration - so CeedQFunctionContextGetDoubleRead works on such a field and SCALAR never appears as a stored label - or should SCALAR be stored distinctly, with a compatibility rule in the type check on access rather than a plain equality test?

My plan after these are finalised:
extend the enum and CeedContextFieldTypes, add the Register* wrappers and the Set*/Get*Read/Restore*Read triples at both the QFunctionContext and Operator levels, update the generic register/set/get/restore paths, regenerate the Julia bindings, and extend tests/t407-qfunction. Atomic commits, with make prove-all and make format before submitting.

[jeremylt]

For 1) yea, we do want to go ahead and do a renumbering. We're about to release 1.0, so now is a fine time to make ABI changes.

For 2), we want all 3, CEED_CONTEXT_FIELD_SCALAR, CEED_CONTEXT_FIELD_DOUBLE, and CEED_CONTEXT_FIELD_FLOAT. So, the field size would be determined by

  switch (field_type) {
    case CEED_CONTEXT_FIELD_BOOL:
      field_size = sizeof(bool);
      break;
    case CEED_CONTEXT_FIELD_BYTE:
      field_size = sizeof(char);
      break;
    case CEED_CONTEXT_FIELD_INT:
      field_size = sizeof(CeedInt);
      break;
    case CEED_CONTEXT_FIELD_INT32:
      field_size = sizeof(int32);
      break;
    case CEED_CONTEXT_FIELD_INT64;
      field_size = sizeof(int64);
      break;
    case CEED_CONTEXT_FIELD_SCALAR:
      field_size = sizeof(CeedScalar);
      break;
    case CEED_CONTEXT_FIELD_FLOAT:
      field_size = sizeof(float);
      break;
    case CEED_CONTEXT_FIELD_DOUBLE:
      field_size = sizeof(double);
      break;
  }

So yea, the compatibility would be determined by calling the correct CeedQFunctionGetContext* function.

@zatkins-dev what about the ordering I give above? It keeps the integer types together. Also, do we want to include CeedInt8? (that's a signed char). What about CeedSize?

[zatkins-dev]

I like your ordering! Adding additional int types doesn't hurt, imo it's better to have a more complete interface for contexts

[jeremylt]

  switch (field_type) {
    case CEED_CONTEXT_FIELD_BOOL:
      field_size = sizeof(bool);
      break;
    case CEED_CONTEXT_FIELD_BYTE:
      field_size = sizeof(char);
      break;
    case CEED_CONTEXT_FIELD_INT8:
      field_size = sizeof(CeedInt8);
      break;
    case CEED_CONTEXT_FIELD_INT:
      field_size = sizeof(CeedInt);
      break;
    case CEED_CONTEXT_FIELD_INT32:
      field_size = sizeof(int32_t);
      break;
    case CEED_CONTEXT_FIELD_INT64;
      field_size = sizeof(int64_t);
      break;
    case CEED_CONTEXT_FIELD_SIZE:
      field_size = sizeof(CeedSize);
      break;
    case CEED_CONTEXT_FIELD_SCALAR:
      field_size = sizeof(CeedScalar);
      break;
    case CEED_CONTEXT_FIELD_FLOAT:
      field_size = sizeof(float);
      break;
    case CEED_CONTEXT_FIELD_DOUBLE:
      field_size = sizeof(double);
      break;
  }

We may want to adjust the names of those to be

int CeedQFunctionContextRegisterCeedInt8(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterCeedSize(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterCeedInt(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);
int CeedQFunctionContextRegisterCeedScalar(CeedQFunctionContext ctx, const char *field_name, size_t field_offset, size_t num_values, const char *field_description);

and so on (also for the CeedQFunctionContextSet*, CeedQFunctionContextGet*Read, CeedQFunctionContextRestore*Read, CeedOperatorGetContext*Read and CeedOperatorRestoreContext*Read), since CeedQFunctionGetContextSizeRead is possibly more confusing than CeedQFunctionGetContextCeedSizeRead. Thoughts?

[ksd-2005]

Both works. We can use CeedQFunctionGetContextCeedSizeRead to sound more clear.
Shall I proceed with this?

[jeremylt]

I'd like @zatkins-dev to chime in on the naming since he's a primary dev over here

[zatkins-dev]

Yeah, I agree with Jeremy that the CeedInt, etc. types should use CeedInt, etc in the function name instead of just Int.

[zatkins-dev]

@ksd-2005 thanks for picking this up! Feel free to ask if you are unsure about anything with the project. Just a reminder that any LLM use (if you choose to use them) should be fully disclosed in the PR.