# Inconsistencies for GOME-2 using harp for python

**URL:** https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593
**Category:** HARP
**Tags:** python
**Created:** [January 16, 2023, 4:20pm UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593 "2023-01-16T16:20:43Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![chrisbo](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/c/8baadc/32.png) [@chrisbo](https://forum.atmospherictoolbox.org/u/chrisbo)
#### Post date: [January 16, 2023, 4:20pm UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/1 "2023-01-16T16:20:43Z")

</div>

Hi,  
I have just processed GOME-2 L1b data (reprocessed GOME-2 data from the recently published FDR) and wanted to combine and compare it with the results of QA4ECV. To do this, I first analysed the same L1B file with the same algorithm on my local PC (with harp v1.11) and then on an HPC cluster (harp v1.17) and got different results. I attached a plot of the course of the latitude for both versions.  
Do the different harp versions merge the data differently?

Kind regards,  
Christian

 ![harp_comparison_latitude](https://forum.atmospherictoolbox.org/uploads/default/original/1X/aa41e1c2d158ab5c587570306136f3346b2dd053.png)

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [January 16, 2023, 5:19pm UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/2 "2023-01-16T17:19:36Z")

</div>

It looks like some sorting issue.

Can you let me know which L1b product you are showing? We might then be able to see if we can reproduce this.

Also, did you use an operations as part of the harp import? (if so, please provide them)

---

<div class="post-metadata">

### Author: ![chrisbo](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/c/8baadc/32.png) [@chrisbo](https://forum.atmospherictoolbox.org/u/chrisbo)
#### Post date: [January 16, 2023, 7:03pm UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/3 "2023-01-16T19:03:43Z")

</div>

An examplary file would be  
GOME\_xxx\_1B\_M02\_20080103043558Z\_20080103062058Z\_R\_O\_20201222112133Z\_0300.nat  
from the L1B fundamental data record ([EUMETSAT Product Navigator](https://navigator.eumetsat.int/product/EO:EUM:DAT:0533)).  
I don’t use an operation, but I read/open the file as follows:

```auto
pro = harp.import_product(gome2fn, options='band=band-4')
lat = pro.latitude.data
lon = pro.longitude.data

```

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [January 17, 2023, 9:33am UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/4 "2023-01-17T09:33:00Z")

</div>

I can’t seem to reproduce this with HARP 1.17 on my machine.  
I have no clue what is going on here.  
Do you have the same out-of-order problem if you plot `datetime` or `index`?

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [January 17, 2023, 9:34am UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/5 "2023-01-17T09:34:53Z")

</div>

Are you also sure that you are using the exact same L1b file? Because the product consists of a sequence of records and if those records in the product are out of order, then harp will likely ingest them out of order in the same way.

---

<div class="post-metadata">

### Author: ![chrisbo](https://forum.atmospherictoolbox.org/letter_avatar_proxy/v4/letter/c/8baadc/32.png) [@chrisbo](https://forum.atmospherictoolbox.org/u/chrisbo)
#### Post date: [January 17, 2023, 10:06am UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/6 "2023-01-17T10:06:49Z")

</div>

I have just noticed that it is a problem between different Pandas versions (1.3.3 vs 1.5.2). When I finally merge the fit results from the DOAS analysis, it seems that pd.concat automatically sorts in the older version, even though this parameter is set to False per default. However, when I explicitly set this parameter in the new version, everything looks fine again.  
I am very sorry to have caused you any inconvenience.

---

<div class="post-metadata">

### Author: ![sander.niemeijer](https://forum.atmospherictoolbox.org/user_avatar/forum.atmospherictoolbox.org/sander.niemeijer/32/5_2.png) [@sander.niemeijer](https://forum.atmospherictoolbox.org/u/sander.niemeijer)
#### Post date: [January 17, 2023, 10:17am UTC](https://forum.atmospherictoolbox.org/t/inconsistencies-for-gome-2-using-harp-for-python/593/7 "2023-01-17T10:17:50Z")

</div>

No problem. Glad you solved it.
