datamodel Level1b when converted to RampModel does not change data type to float

[stscijgbot-jp]

Issue JP-3826 was created on JIRA by Maria Pena-Guerrero:

When converting a datamodel of type Level1b to RampModel, the data type does not covert from integer to float. If a user does 

dm = datamodels.open(uncal_file)
Detector1Pipeline.call(dm)```
The pipeline crashes with an error like
```java
 File "/Users/pena/Documents/SCSB/jwst/jwst/jwst/emicorr/emicorr.py", line 450, in apply_emicorr
    output_model.data[..., noise_x + k] -= dd_noise
numpy.core._exceptions._UFuncOutputCastingError: Cannot cast ufunc 'subtract' output from dtype('float32') to dtype('uint16') with casting rule 'same_kind' ```
This happens with data from all instruments, not only MIRI, and not only at the emicorr step.

A minimal reproducer of the issue is as follows:
```java
import numpy as np 
import stdatamodels.jwst.datamodels as dm 

ramp_from_fn = dm.RampModel("miri_uncal.fits") # det1 with a filename assert ramp_from_fn.data.dtype == np.float32 
m = dm.open("miri_uncal.fits") # produces the expected Level1bModel 
# what happens when det1 is called with an open model
ramp_from_lvl1b = dm.RampModel(m) 
assert ramp_from_lvl1b.data.dtype == np.uint16

The reason for this happening is that calling RampModel(model) creates a shallow clone of model, which doesn't copy arrays (that can be seen adding this to the above example {}assert m.data is ramp_from_lvl1b.data{}). This behavior is at least 6 years old and is documented as intended (see the description of the "shallow copy" here 6ff2a48a7018f45d5afa5e279924cab6f1c5eefb])

However, since the pipeline uses RampModel(some_level1b_model) quite often, it can lead to the crash due to different data types. The recommendation would be to override RampModel.clone (or maybe the {}*_init_*{}) to cast the arrays to the new dtypes.