[Difx-users] DiFX version for VGOS data correlation {External}

[Walter Brisken]

Hi Mike (and others),

Anyone having issues with the new vex2difx (with vex2 support), please 
either use this list or send mail directly to me.  For any corrections to 
be done I will need the full set of files needed to run vex2difx.

Jan Wagner already identified one case where the vex2-enabled vex2difx did 
not work for an EHT project.  The issue ended up being one where the vex 
file was incomplete but the previous version of vex2difx "filled in the 
blanks".  We agreed that the correct course of action for that particular 
case was bringing the vex file up to standards.

I would encourage testing of trunk vex2difx (and reporting of issues) 
sooner rather than later if possible.  There is still a low level of 
activity on this.  After it dies down it will be harder to jump back in 
for fixes!

I have started gathering a set of vex2 files (and their vex1.5 
counterparts) that can be used for comparisons.  I would appreciate 
additional contributions (you can add them within the vex2testdata 
subdirectory of trunk vex2difx.

 	-Walter

P.S. Mike: I think the python3 issue you are having must be related to a 
broken installation of some software or a problem with the environment of 
the user attempting to run the program.  This does not sound like a 
DiFX-specific problem.

-------------------------
Walter Brisken
NRAO
Deputy Assistant Director for VLBA Development
(505)-234-5912 (cell)
(575)-835-7133 (office; not useful during COVID times)

On Fri, 11 Mar 2022, Mike Titus via Difx-users wrote:

>
> Just an FYI on something I discovered only a couple weeks ago because I have 
> not tested the trunk in a long time.  The trunk currently refuses to parse 
> VGOS vex/v2d setups I have used for years and work in all tagged versions 
> (including your latest 2.7 build) i.e. right now it's entirely broken for 
> VGOS.  Have not had time to pursue it yet. Probably coincident with the vex2 
> changes.
>
> Also just because it's been so long, I tried to run my little heartbeat test 
> schedule on the trunk (totally generic i.e. from the example on the DIFX 
> site) and that won't run either, complaining about shared libraries:
>
> python3: error while loading shared libraries: libssl.so.1.1: cannot open 
> shared object file: No such file or directory
>
> Note the same test works with 2.5.4 and 2.7 (tested at the same time). This 
> is on po, BTW.
>
> On Thu, 10 Mar 2022, Geoff Crew via Difx-users wrote:
>
>>  The issues have to do with the way complex spectra are processed and
>>  handled in the backends and DiFX.  2.5.4 was created as a stable
>>  processing release for VGOS until the resources were free to guarantee
>>  operation in a "current" release.  And fixing this situation requires some
>>  coordination with the way backends are operated.  I'm not fluent in the
>>  details.
>>
>>  A 2.7.1 release for the EHT processing of the 2021 campaign is likely to
>>  occur in the next few months (as the media need to be recycled) and a
>>  2.7-based release suitable for VGOS was one of the options discussed, but
>>  I do not know the current plan for VGOS.
>> 
>>
>>  On 3/10/22 15:07, Michael Dutka via Difx-users wrote:
>>>  Hi Difx Users,
>>>  Currently, as I understand things, it is advised that DiFX version
>>>  2.5.4 should be used to correlate VGOS data.  I was wondering if
>>>  anyone here had any documentation explaining why that's necessary and
>>>  why we can not use the latest tagged release?  I was also wondering if
>>>  anyone is working on making sure VGOS correlation will be able to be
>>>  done with future versions of DiFX?
>>>  Any help with this would be greatly appreciated!
>>>  -Mike
>>>
>>  --
>>  Geoff Crew
>>  gbc at haystack.mit.edu
>>
>>  _______________________________________________
>>  Difx-users mailing list
>>  Difx-users at listmgr.nrao.edu
>>  https://listmgr.nrao.edu/mailman/listinfo/difx-users
>> 
>