Hello James and all,

It's been seven months since Patrick so rapidly forwarded to me the
SQL batch file that would make all of these position corrections.  My
apologies to everyone on letting this slip past me.  But the
corrections have now been imported.

-Christopher

On Jun 3, 2007 12:55 PM, Patrick Wils <patrickwils@...> wrote:
> Yes, it seems I lost a decimal in RA.  I'll correct this.
>
>
> Patrick
>
> --- James Bedient <jbedient@...> wrote:
>
> > When Skiff's MKTypes.dat file info was input to VSX, some of the
> > positions, which were used to override the existing positions, were
> > put in incorrectly.
> >
> > Example:
> >
> > VSX J084716.7-471324
> >
> > Position I gave:          08 47 16.77 -47 13 24.6
> > Position in Skiff's file: 08 47 16.77 -47 13 24.6
> > (No shock, same source, UCAC2)
> >
> > Position in VSX, attributed to Skiff: 08 47 16.70 -47 13 24.6
> >
> > The ones I've looked at have all had the last decimal place of RA
> > changed to 0.
> >
> > OK, it's only 0.07" of RA, but the correct numbers are the correct
> > numbers.
> >
> > Jim

Has there been any progress on publishing the new discoveries entered
into VSX? James last raised the subject back in December and I don't
recall reading any update since then.

--- In vsx-dis@yahoogroups.com, arne <arne@...> wrote:
>
> James Bedient wrote:
> > There has been a lot of discussion about how to disseminate the
> > results placed in VSX, and this seemed to me to be seen as
important
> > to the viability of VSX.
> >
> > Has there been any progress on this front?  Any plans in the
works?
> >
> > I'd like to make my own suggestion, and that's an electronic
> > Supplement to JAAVSO.  Establish it as a web-only HTML
publication,
> > not open to submissions other than new variables, improved
positions,
> > types, periods, etc. via VSX.  Publish it once a quarter, have it
> > fully indexed in SIMBAD and ADS, with everyone who submits
accepted
> > information as co-authors.  I'm starting to think that this may
be the
> > only way to keep VSX viable as the master database we all think it
> > should be.
> >
> > Another issue is that we need to get VSX IDs into SIMBAD.
> >
> We are working on it, really.  Unfortunately, at the current time
most
> everything falls into one person's lap, and until we solve that
problem,
> things must wait.  This is an internal situation that does not need
> public airing, and we're just making slower headway that I'd like.
>
> The same goes for VSX publication.  Remember that, right at the
*very*
> beginning of the new star submission wizard, we specifically state
that
> submitting new stars does not consitute publication, nor should you
assume
> that any supporting datafiles will be archived.  Even so, my goals
are to have
> lists published in JAAVSO, and to get cross-linking with Simbad, by
> mid-summer so that we have a full year of visibility before the IAU
2009
> meeting.  I think there will be some interesting variable star
> proposals at that meeting, and want the AAVSO and VSX to be properly
> positioned.  Everything else relating to this is politics, and I'm
> not going to say more on a public discussion group.
> Arne
>

There's nothing to stop you submitting them for publication to oejv,
pzp or ibvs, which if successful would mean they would get into some
bibliographic hyper-indices anyway

--- In vsx-dis@yahoogroups.com, "martin_piers_nicholson"
<martin_piers_nicholson@...> wrote:
>
> Has there been any progress on publishing the new discoveries entered
> into VSX? James last raised the subject back in December and I don't
> recall reading any update since then.
>
> --- In vsx-dis@yahoogroups.com, arne <arne@> wrote:
> >
> > James Bedient wrote:
> > > There has been a lot of discussion about how to disseminate the
> > > results placed in VSX, and this seemed to me to be seen as
> important
> > > to the viability of VSX.
> > >
> > > Has there been any progress on this front?  Any plans in the
> works?
> > >
> > > I'd like to make my own suggestion, and that's an electronic
> > > Supplement to JAAVSO.  Establish it as a web-only HTML
> publication,
> > > not open to submissions other than new variables, improved
> positions,
> > > types, periods, etc. via VSX.  Publish it once a quarter, have it
> > > fully indexed in SIMBAD and ADS, with everyone who submits
> accepted
> > > information as co-authors.  I'm starting to think that this may
> be the
> > > only way to keep VSX viable as the master database we all think it
> > > should be.
> > >
> > > Another issue is that we need to get VSX IDs into SIMBAD.
> > >
> > We are working on it, really.  Unfortunately, at the current time
> most
> > everything falls into one person's lap, and until we solve that
> problem,
> > things must wait.  This is an internal situation that does not need
> > public airing, and we're just making slower headway that I'd like.
> >
> > The same goes for VSX publication.  Remember that, right at the
> *very*
> > beginning of the new star submission wizard, we specifically state
> that
> > submitting new stars does not consitute publication, nor should you
> assume
> > that any supporting datafiles will be archived.  Even so, my goals
> are to have
> > lists published in JAAVSO, and to get cross-linking with Simbad, by
> > mid-summer so that we have a full year of visibility before the IAU
> 2009
> > meeting.  I think there will be some interesting variable star
> > proposals at that meeting, and want the AAVSO and VSX to be properly
> > positioned.  Everything else relating to this is politics, and I'm
> > not going to say more on a public discussion group.
> > Arne
> >
>

As your VSX variables have passed moderation and been included into VSX they
should therefore have sufficient data and be suitable enough for you to submit
them in a paper to JAAVSO yourself.  If you are a fee paying member of AAVSO
publication should be free and submission processing primarily a formality, for
after all what's there to referee if you've already got them past the VSX
submission procedure.

--- In vsx-dis@yahoogroups.com, interferom <interferom@...> wrote:
>
>
> As your VSX variables have passed moderation and been included into
VSX they should therefore have sufficient data and be suitable enough
for you to submit them in a paper to JAAVSO yourself.  If you are a
fee paying member of AAVSO publication should be free and submission
processing primarily a formality, for after all what's there to
referee if you've already got them past the VSX submission procedure.
>

Hi John

Thanks for the advicegiven. At present I am fully occupied with
preparing the 2009 edition of "South African Postcard Values". It is
the monsoon season in New Mexico so I am trying to get this other
work done over the summer.

Martin Nicholson
Daventry, UK

For what its worth, I joined vsx-dis just as I was thinking that a
query based on the observer's location, a filter on the altitude of
the object, and magnitude would be a nice addition.

I just ran across what Shawn Dvorak at Rolling Hills Observatory has
done. As a beginner, it found it ideal for the opportunist search.
The "What's up?...now that I have good weather..search."

http://www.rollinghillsobs.org/perl/calcRRephem.pl
http://www.rollinghillsobs.org:8000/perl/calcEBephem.pl

My apologizes if VSX already has this feature. I didn't see it, though
I've only just joined AAVSO today.

Michael

--- In vsx-dis@yahoogroups.com, arne <arne@...> wrote:
>
> martin_piers_nicholson wrote:
> > VSX encourages people like me to observe previously neglected
> > variables. It would be useful if, in effect, all VSX entries were
> > automatically in the AAVSO validation file so that results submitted
> > could be seen graphically. I appreciate that it is possible to get
> > stars added to the file on request but automatic inclusion might
offer
> > some advantages.
> >
> That feature is coming soon.
> Arne
>

No, Michael...VSX does not have that feature.  Sounds like a good
idea, at first blush, although I don't think we ever envisioned VSX as
being an observation planning tool, per se.  At least not in the
context of a particular observer's geo-location.  Paul Rodman's
AstroPlanner does a REALLY good job of that, but of course can't take
advantage of the entire VSX dataset...yet.  I have been talking with
Paul about engineering some VSX query capability into AstroPlanner so
that it can bring up real-time VSX variables for a given sky view.
Maybe we can make that happen.  Paul's typically very accommodating
about that kind of thing.

VSX does have basic magnitude filtering, though.

Christopher Watson
AAVSO VSX

On Mon, Sep 8, 2008 at 11:53 PM, michael.kran <michael.kran@...> wrote:
> For what its worth, I joined vsx-dis just as I was thinking that a
> query based on the observer's location, a filter on the altitude of
> the object, and magnitude would be a nice addition.
...
> My apologizes if VSX already has this feature. I didn't see it, though
> I've only just joined AAVSO today.

I believe Paul has AstroPlanner catalogs for the GCVS and NSV (plus
supplement), so a good amount of bona-fide and suspected variables for
use in the program right there.  Of course, Paul can't keep these
catalogs in lock-step with the relentless advancements in the
refinement of their data, so that's why it would be a great idea for
AstroPlanner to be able to query VSX in the background for ALL
variables known to us within a given field of view.  His program would
then be able to show, for example, that a new nova-like object that
just popped off last night (and got submitted to VSX a few hours ago)
culminates at 0230 that night.

We'll see what we can do.

-Christopher

On Tue, Sep 9, 2008 at 1:10 AM, Michael Kran <michael.kran@...> wrote:
> Thank you for your reply. I have AstroPlanner, but I had not
> thought of it in terms of variable stars, even a sub-set of VSX.
> That would be a great solution!

There is an interesting debate on VSX underway at:

http://simostronomy.blogspot.com/2008/07/international-variable-star-
index-vsx.html

While readers might not agree with everything that has appeared there I
think that the concerns and issues raised - more in sorry than anger -
need careful consideration.

For example I wrote "The Cambridge meeting was excellent, the newly
available remote access scopes will be helpful to members and I have no
issue with the new LPV group. However all this "hustle and bustle" does
not hide the lack of progress on this aspect of VSX."

Why not share your views, either here or there?

Debate on VSX - continued

The debate is starting to draw to a close now. Some very forthright
views have been expressed and some fundamental misunderstandings and
miscommunications have been exposed.

I still think it is the "how and when" rather than "if" of publishing
the new variables submitted to VSX that remained to be resolved.

Martin Nicholson
Daventry, UK

Sebastian,

>>>>>>>>>>>>>>>>>>
Just to tell submitters that the official format for the recently released UCAC3
catalog (see
http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad)
is:
3UCAC FFF-NNNNNN instead of UCAC2 NNNNNNNN as in the UCAC2 catalog.

It will surely be a source of confusion.
<<<<<<<<<<<<<<<<<<


This seems to contradict what is in the UCAC3 README file:

>>>>>>>>>>>>>>>>>>>>>
Official UCAC3 star ID numbers should be utilized for identification purposes
and for communication with the UCAC team. The main
identifier is the running star number in the CCD mean position data (MPOS
number) which is provided on the UCAC3 individual star
records as the last 4-byte integer item. This number spans the range of 3 to
140051297 but includes gaps for stars which did not
make it into the release. MPOS numbers over 140 million identify high proper
motion stars, which have been handled differently in
the pipeline and were merged at a later stage into the release.

Alternatively, a unique running star ID number without any gaps can be generated
on the fly, counting stars along zones from south
to north and along RA within each zone, similarly to what was recommended for
UCAC2.

         ID = n0 + running star number in zone z

where z is zone number where the star in question is located (1 to 360; zone 1:
-90 to -89.5 decl., ...), n0 is the largest star ID
number of the previous zone and ID is this official UCAC3 star ID number. A
table is provided listing some statistics of zones,
which include this n0 number.

If needed, this 9-digit star ID number should be given in connection with the
IAU sanctioned acronym of this project and this data
release number, such as "3UCAC100200300". The star ID number runs from 000000001
to 100766420. Leading zeros are to be used to fill
9 digits in the star name.
>>>>>>>>>>>>>>>>>>>>>

I find no reference in the README to the 3UCAC NNN-XXXXXXX format. I may have
just
missed it.

Note also that the largest number given on the SIMBAD page (N=100765502) does
not
agree with the largest number given in the README (N = 100766420).

You're right: it truly is a source of confusion.


Clear Skies
Brian D. Warner
Palmer Divide Observatory
http://www.MinorPlanetObserver.com

Collaborative Asteroid Lightcurve Link
http://www.MinorPlanetObserver.com/astlc/default.htm

Brian,

> If needed, this 9-digit star ID number should be given in connection with
> the IAU sanctioned acronym of this project and this data
> release number, such as "3UCAC100200300". The star ID number runs from
> 000000001 to 100766420. Leading zeros are to be used to fill
> 9 digits in the star name.
>>>>>>>>>>>>>>>>>>>>>>
>
> I find no reference in the README to the 3UCAC NNN-XXXXXXX format. I may
> have just
> missed it.
>
> Note also that the largest number given on the SIMBAD page (N=100765502)
> does not
> agree with the largest number given in the README (N = 100766420).
>
> You're right: it truly is a source of confusion.


Well, the acronym seems to be 3UCAC. The format seems to be different
though, but I would follow what's stated in the SIMBAD dictionary of
nomenclature.


Wolfgang,

> Bill J Gray of projectpluto.com writes at:
> http://www.projectpluto.com/new.htm
> for his most recent Guide8 "in-testing" update:

>>> UCAC-3 numbering modified: UCAC-3 has rapidly passed from its original
>>> designation scheme to an alternative, and a new, final scheme has been
>>> settled upon.
Originally, UCAC-3 stars all had numbers ranging from 1 to slightly over 100
million, giving each star a sequential number with no gaps. Then VizieR
chose the MPOS number, which runs from 1 to slightly over 140 million, with
many gaps. The final decision, made by USNO, was that a UCAC-3 identifier
consists of '3UC' followed by a three-digit zone identifier running from 1
to 360, a dash, and six digits. Thus, '3UC314-159265' would be the 159265th
star in zone 314.
Guide will now show the correct identifier for all UCAC-3 stars, both when
shown from the original data files and from VizieR downloads.
Also, if you have the UCAC-3 data on your hard drive, you can use Go To...
Object name and enter (for example) "3UC314-159265", and Guide will find the
relevant star.
Also, the 'more info' section is more informative, with some UCAC-3 specific
glossary definitions. <<<


I knew it would be s ource of confussion.
So we have a lot of names said to be official in their own way.
I would still use the one given in the Dictionary of Nomenclature but maybe
someone with more authority can guide us.

If we are not to trust the Dictionary as a guide, then where should we look
at??

Cheers,
Sebastian.

http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad?/10531273

The Dictionary of Nomeclature is supposed to be the up-to-date
electronic repository of the acronyms and designation formats approved
in the Working Group on Astronomical Designations of IAU Commission 5.
  Therefore, the notes

Write: <<3UCAC FFF-NNNNNN>>

and

***** Avoid the usage of UCAC3, prefer 3UCAC

would seem to indicate that it is indeed 3UCAC which is the approved
acronym, and that the entire designation follows the field and star
number format described in the note from Bill Gray.

-Christopher

Subject: Re: [vsx-dis] UCAC3 identifier format.


> http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad?/10531273
>
> The Dictionary of Nomeclature is supposed to be the up-to-date
> electronic repository of the acronyms and designation formats approved
> in the Working Group on Astronomical Designations of IAU Commission 5.
> Therefore, the notes
>
> Write: <<3UCAC FFF-NNNNNN>>
>
> and
>
> ***** Avoid the usage of UCAC3, prefer 3UCAC
>
> would seem to indicate that it is indeed 3UCAC which is the approved
> acronym, and that the entire designation follows the field and star
> number format described in the note from Bill Gray.
>
> -Christopher



http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad?text=UCAC3&cat=Identifier+starting\
+by&out=SIMBAD+Usage&max=Maximum+of+50+entries#

Now the format is given as UCAC3 FFF-NNNNNN

Worse still, VizieR says:

UCAC3 designation (1)
Note (1)  : the 3UC number is the recommended identification of UCAC3 stars.
It made as "zzz-nnnnnnn", where zzz is the zone number (between 1 and 360
from South pole to North pole), and nnnnnn a 6-digit running number in the
zone. For instance, 3UC180-000007 designates the 7th star in the 180th zone
(declination range between -0.5 and 0.0°)

So we started as 3UCAC FFF-NNNNNN, now the SIMAD dictionary changed it to
UCAC3 FFF-NNNNNN and VizieR says 3UCFFF-NNNNNN...

Weren't these things supposed to be worked out before a public release???

Cheers,
Sebastian.

There was a boat-load of things in UCAC3 that should have been worked
out before a public release -- of those, nomenclature being the most
trivial by far!

-Christopher

On Wed, Oct 28, 2009 at 3:47 PM, Sebastián Otero <varsao@...> wrote:
> Subject: Re: [vsx-dis] UCAC3 identifier format.
>
>
>> http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad?/10531273
>>
>> The Dictionary of Nomeclature is supposed to be the up-to-date
>> electronic repository of the acronyms and designation formats approved
>> in the Working Group on Astronomical Designations of IAU Commission 5.
>> Therefore, the notes
>>
>> Write: <<3UCAC FFF-NNNNNN>>
>>
>> and
>>
>> ***** Avoid the usage of UCAC3, prefer 3UCAC
>>
>> would seem to indicate that it is indeed 3UCAC which is the approved
>> acronym, and that the entire designation follows the field and star
>> number format described in the note from Bill Gray.
>>
>> -Christopher
>
>
>
>
http://cdsweb.u-strasbg.fr/cgi-bin/Dic-Simbad?text=UCAC3&cat=Identifier+starting\
+by&out=SIMBAD+Usage&max=Maximum+of+50+entries#
>
> Now the format is given as UCAC3 FFF-NNNNNN
>
> Worse still, VizieR says:
>
> UCAC3 designation (1)
> Note (1)  : the 3UC number is the recommended identification of UCAC3 stars.
> It made as "zzz-nnnnnnn", where zzz is the zone number (between 1 and 360
> from South pole to North pole), and nnnnnn a 6-digit running number in the
> zone. For instance, 3UC180-000007 designates the 7th star in the 180th zone
> (declination range between -0.5 and 0.0°)
>
> So we started as 3UCAC FFF-NNNNNN, now the SIMAD dictionary changed it to
> UCAC3 FFF-NNNNNN and VizieR says 3UCFFF-NNNNNN...
>
> Weren't these things supposed to be worked out before a public release???
>
> Cheers,
> Sebastian.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Hi Gene

> Is there a list of the Variable Type field values in the
> Variable Star Index?

No, not that I know of.

> The reason I'm asking is because some of the eclipsing
> binaries I'm observing/planning to observe (U Cep, Beta Per,
> Epsilon Aur) have "EA" for the type and I expected to see "EB."

Your expectations are not correct !

EB is the general acronym for "Eclipsing Binary".

But if a var type is meant, its defined as following:
EA = EBs of A = Algol subtype.
EB = EBs of B = beta Lyr subtype.
EW = EWs of W = W UMa subtype.
So giving the var type EA for all these EBs is correct.
Tricky, isn't it ? Sometimes even the experts might not know
if  EB means  "Eclipsing Binary" or "EB of beta Lyr subtype".

> Most also have a forward slash and a second abreviation.
> I seached for a complete list but couldn't find one. If

Most var types in the VSX originate from the GCVS.
These are originally described here:
http://www.sai.msu.su/gcvs/gcvs/iii/vartype.txt
http://cdsarc.u-strasbg.fr/viz-bin/getCatFile/w/_Redirect?B/gcvs/vartype.txt

A short overview of var types by the ATNF:
http://outreach.atnf.csiro.au/education/senior/astrophysics/variable_types.html
Short list of var types by the ASSA:
http://www.assa.org.au/sig/variables/classifications.asp
Extended summary with light curves (LCs) by the AEOFV:
http://cdsarc.u-strasbg.fr/afoev/var/typo.htx (french)
http://cdsarc.u-strasbg.fr/afoev/var/etypo.htx (english)
and GEA at:
http://www.astrogea.org/VARIABLE/tipus/index.htm (spanish)
HIP subset of GCVS var types:
http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/239#sRM99.1
http://www.rssd.esa.int/Hipparcos/CATALOGUE_VOL1/sect2_04.pdf
http://nsted.ipac.caltech.edu/NStED/docs/parhelp/HipVarTypeTable.html


If a var type is not in the above GCVS lists, its probably specific
for the paper/catalog that is given in the VXSX references. Some
of the additionally used var types are e.g. defined here:

Downes CVcat:
http://archive.stsci.edu/prepds/cvcat/description.html#type

Ritter & Kolb RKcat:
http://heasarc.gsfc.nasa.gov/W3Browse/star-catalog/rittercv.html#type1

More modern pulsating var types:
2008CoAst.157..240J - The impact of asteroseismology on the theory
of stellar evolution - Jeffery, C. S.
http://adsabs.harvard.edu/abs/2008CoAst.157..240J
Figure 1: Schematic Hertzsprung-Russell diagram showing the locus of
major classes of pulsating variable star.

IAUS 272 on Actives OB stars
http://www.shelyak.com/dossier.php?id_dossier=50&lang=2

...

Clear skies
  Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany

> IAUS 272 on Actives OB stars
> http://www.shelyak.com/dossier.php?id_dossier=50&lang=2

The SPB and BCEP descriptions in that webpage are interchanged. The longer
period stars are the SPB ones.

You can also add DPV's
http://arxiv.org/abs/0910.4359v1
Binary Be stars showing the orbital variability (EA, EB or ELL) superposed
to a longer term variation (30-40 times longer than the orbital period)
caused by the periodic formation and dissipation of a disk.

A couple of YSO (Young Stellar Objects) classes are (and can be defined as):

EX= EXors or Subfuors, subspecies of the FU class. They are named after EX
Lupi. They are eruptive T Tauri stars that show brightening episodes of
several magnitudes in time scales of several months or a few years. They
possibly represent an intermediate state between normal T Tauri stars and FU
Ori stars. (Examples: EX Lup, V1118 Ori, V1143 Ori)

UX= UXors (UX Ori stars). Herbig Ae/Be stars that show irregular variations
with a wide range of amplitudes from barely detectable to more than 4 mag in
V. Large-amplitude variability is confined to stars with spectral types
later than B8. There are two principal components: (1) irregular variations
on timescales of days around a mean brightness level that changes on a much
longer timescale (typically years), sometimes in a quasi-cyclic fashion, and
(2) occasional episodes of deep minima, occurring at irregular intervals but
more frequently near the low points of the brightness cycles (extracted from
ref. 0081) (Examples: UX Ori, CQ Tau, BF Ori)

Cheers,
Sebastian.

Hi Chris

FYI

I just noticed that the VSX "Atlas of O-C Diagrams for EBs" URLs are built
incorrectly due to an additional "25":

E.g. VSX tries to load the page:
http://www.as.up.krakow.pl/o-c/data/getdata.php3?Y%2520Cyg
should actually read:
http://www.as.up.krakow.pl/o-c/data/getdata.php3?Y%20Cyg

It would be also good to update:
http://www.aavso.org/vsx/index.php?view=about.bugs
as AAVSO Bugzilla doesn't exist anymore already for some month.

Thx.

Clear skies
  Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany

Hi Chris

FYI

I just noticed that the VSX "AAVSO LCG" URLs are built incorrectly due to
the changed URLs of the new AAVSO web site:

E.g. VSX tries to unsuccessfully create a plot for SDSS J150722.30+523039.8
via the URL:
<http://www.aavso.org/cgi-bin/lcg.pl?auid=SDSS+J150722.30%2B523039.8&lastdays=20\
0&start=&stop=&obscode=&obscode_symbol=2&visual=on&uband=on&bband=on&v=on&obstot\
als=on&grid=on&pointsize=1&width=600&height=425&mag1=&mag2=&mean=&vmean=&button_\
name=Please+Wait...>

The equivalent URL for the new AAVSO web site is:
<http://www.aavso.org/lcg/plot?auid=000-BJQ-853&starname=SDSS%20J150722.30+52303\
9.8&lastdays=200&start=&stop=&obscode=&obscode_symbol=2&obstotals=yes&grid=on&ub\
and=on&bband=on&v=on&visual=on&r=on&iband=on&unknown=on&unvalidated=on&different\
ial=on&fainterthan=on&pointsize=1&width=800&height=600&mag1=&mag2=&mean=&vmean=>

It would be also good to update:
http://www.aavso.org/vsx/index.php?view=about.bugs
as AAVSO Bugzilla doesn't exist anymore already for some month.

Thx.

Clear skies
  Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany

Hi Wolfgang,

This should be fixed now.

Patrick


--- On Mon, 1/24/11, Wolfgang Renz <wr-astro@...> wrote:

> From: Wolfgang Renz <wr-astro@...>
> Subject: [vsx-dis] VSX "AAVSO LCG" URLs are built incorrectly
> To: "Christopher Watson" <skygeex@...>
> Cc: "AAVSO VSX DIS" <vsx-dis@yahoogroups.com>, "AAVSO VSX" <vsx@...>
> Date: Monday, January 24, 2011, 12:22 PM
> Hi Chris
>
> FYI
>
> I just noticed that the VSX "AAVSO LCG" URLs are built incorrectly due to
> the changed URLs of the new AAVSO web site:
>
> E.g. VSX tries to unsuccessfully create a plot for SDSS J150722.30+523039.8
> via the URL:
>
<http://www.aavso.org/cgi-bin/lcg.pl?auid=SDSS+J150722.30%2B523039.8&lastdays=20\
0&start=&stop=&obscode=&obscode_symbol=2&visual=on&uband=on&bband=on&v=on&obstot\
als=on&grid=on&pointsize=1&width=600&height=425&mag1=&mag2=&mean=&vmean=&button_\
name=Please+Wait...>
>
> The equivalent URL for the new AAVSO web site is:
>
<http://www.aavso.org/lcg/plot?auid=000-BJQ-853&starname=SDSS%20J150722.30+52303\
9.8&lastdays=200&start=&stop=&obscode=&obscode_symbol=2&obstotals=yes&grid=on&ub\
and=on&bband=on&v=on&visual=on&r=on&iband=on&unknown=on&unvalidated=on&different\
ial=on&fainterthan=on&pointsize=1&width=800&height=600&mag1=&mag2=&mean=&vmean=>
>
> It would be also good to update:
> http://www.aavso.org/vsx/index.php?view=about.bugs
> as AAVSO Bugzilla doesn't exist anymore already for some month.
>
> Thx.
>
> Clear skies
>  Wolfgang
>
> --
> Wolfgang Renz, Karlsruhe, Germany

I'd like to suggest that the last 200 days is not a good choice for
displaying.
A kind of ASAS-like time span gives us the chance to see several cycles and
to find out typical long term behaviour (mean magnitude changes, extreme
magnitudes, outburst recurrence) on each star.
On my data improvement work in VSX I had to make my own LCG plot to find it
useful...
I think that e.g. 3,000 days would be a better default choice.

Cheers,
Sebastian.



----- Original Message -----
From: "Patrick Wils" <patrickwils@...>
To: "Wolfgang Renz" <wr-astro@...>
Cc: "AAVSO VSX DIS" <vsx-dis@yahoogroups.com>; "Christopher Watson"
<skygeex@...>
Sent: Tuesday, January 25, 2011 8:55 PM
Subject: Re: [vsx-dis] VSX "AAVSO LCG" URLs are built incorrectly


> Hi Wolfgang,
>
> This should be fixed now.
>
> Patrick
>
>
> --- On Mon, 1/24/11, Wolfgang Renz <wr-astro@...> wrote:
>
>> From: Wolfgang Renz <wr-astro@...>
>> Subject: [vsx-dis] VSX "AAVSO LCG" URLs are built incorrectly
>> To: "Christopher Watson" <skygeex@...>
>> Cc: "AAVSO VSX DIS" <vsx-dis@yahoogroups.com>, "AAVSO VSX"
>> <vsx@...>
>> Date: Monday, January 24, 2011, 12:22 PM
>> Hi Chris
>>
>> FYI
>>
>> I just noticed that the VSX "AAVSO LCG" URLs are built incorrectly due to
>> the changed URLs of the new AAVSO web site:
>>
>> E.g. VSX tries to unsuccessfully create a plot for SDSS
>> J150722.30+523039.8
>> via the URL:
>>
<http://www.aavso.org/cgi-bin/lcg.pl?auid=SDSS+J150722.30%2B523039.8&lastdays=20\
0&start=&stop=&obscode=&obscode_symbol=2&visual=on&uband=on&bband=on&v=on&obstot\
als=on&grid=on&pointsize=1&width=600&height=425&mag1=&mag2=&mean=&vmean=&button_\
name=Please+Wait...>
>>
>> The equivalent URL for the new AAVSO web site is:
>>
<http://www.aavso.org/lcg/plot?auid=000-BJQ-853&starname=SDSS%20J150722.30+52303\
9.8&lastdays=200&start=&stop=&obscode=&obscode_symbol=2&obstotals=yes&grid=on&ub\
and=on&bband=on&v=on&visual=on&r=on&iband=on&unknown=on&unvalidated=on&different\
ial=on&fainterthan=on&pointsize=1&width=800&height=600&mag1=&mag2=&mean=&vmean=>
>>
>> It would be also good to update:
>> http://www.aavso.org/vsx/index.php?view=about.bugs
>> as AAVSO Bugzilla doesn't exist anymore already for some month.
>>
>> Thx.
>>
>> Clear skies
>>  Wolfgang
>>
>> --
>> Wolfgang Renz, Karlsruhe, Germany
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

> I'd like to suggest that the last 200 days is not a good choice for
> displaying.
>
> I think that e.g. 3,000 days would be a better default choice.

Done.

Patrick

FYI

The time span does need IMO more discussion:

ASAS plots by default all obs they have. This is unpractical for the AAVSO
obs span a much longer time.
If one does just consider LPVs, one could choose a time span of up to ~
20 years to get still nice LCs for most of these stars.
One cann't consider short period EBs and pulsators for this. Maybe even
not Cepheids.
But one should at least consider SRs and RVs  with their usually much
shorter periods too.

gnuplot (that is used for the LCG plots) creates plots with always 4 major
time ticks and 2 or 5 minor time ticks per major time tick.
So if someone wants to get easily readable, whole, round time valuess
for the JD time axis, they should choose the time span of the LCG plots
to be a multiple of 8 or better a multiple of 20.
Choosing 3000d (~ 8 years) for the time span gives major time ticks every
750d and minor time ticks every 150d. Not really odd numbers, but IMO
choosing  4000d (~ 11 years) with 1000d and 200d time ticks, or 2000d
(~ 5.5 years) with 500d and 100d time ticks, or 1000d (~ 3 years) with
250d and 50d time ticks would be better.

When considering medium period SRs and RVs, I plead for a time span
of 2000d (~ 5.5 years) for the LCG plots. This should be sufficient also
for LPVs.

BTW
I would eithe just let plot V, vis, unvalidatred xor also enable the plotting of
R and I too beside U, B, V, vis, unknown, unvalidatred.

Clear skies
  Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany

>>> The time span does need IMO more discussion:

ASAS plots by default all obs they have. This is unpractical for the AAVSO
obs span a much longer time.
If one does just consider LPVs, one could choose a time span of up to ~
20 years to get still nice LCs for most of these stars.
One cann't consider short period EBs and pulsators for this. Maybe even
not Cepheids.


This brings the question of a phase plot option such as ASAS or Hipparcos
have.
And of course that, depending on the star's period, a different time span
option would  be the ideal case.


>>> Choosing 3000d (~ 8 years) for the time span gives major time ticks
>>> every
750d and minor time ticks every 150d. Not really odd numbers, but IMO
choosing  4000d (~ 11 years) with 1000d and 200d time ticks, or 2000d
(~ 5.5 years) with 500d and 100d time ticks, or 1000d (~ 3 years) with
250d and 50d time ticks would be better.


I see your point, maybe a 2,000 d. figure could be chosen then (although I
would prefer 4,000)
It's just to have a first look at the star's behaviour over longer time
frames than 200 d. It was too short for most cases.
But if someone wants a different time span it can be got easily by changing
the URL from "lastdays=2000 to lastdays=200" or whatever.


>>> I would eithe just let plot V, vis, unvalidatred xor also enable the
>>> plotting of
R and I too beside U, B, V, vis, unknown, unvalidatred.

I think that if you're so interested in that star in particular, you can
take your time to go to the LCG page and set all the parameteres as you
wish. I think that only displaying visual observations for the VSX entry is
a good choice, I wouldn't wnat to have all kinds of mixed symbols if I just
wanted to see the star's general behaviour over the recent years.

Best wishes,
Sebastian

> The time span does need IMO more discussion:

I have made the timespan depend on the period: a rounded number of days of at
least 10 cycles and at least 400 days.  When there is no period I have used 2000
days.

> gnuplot (that is used for the LCG plots) creates plots with always 4
> major time ticks and 2 or 5 minor time ticks per major time tick.

Actually the LCG itself does it that way.  By default gnuplot will use a wider
diversity in the number of major ticks and no minor ticks.

Patrick

Hello

I just logged into VSX and tried to add a reference to a var.
But the VSX: "Add reference" link is always grayed out with any var I've
looked at.

Is this on purpose that "normal" users cann't add new references anymore ?

Clear skies
  Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany

Hi Wolfgang,

Yes, references can now only be added through a revision.

Patrick



----- Original Message -----
From: Wolfgang Renz <wr-astro@...>
To: AAVSO VSX <vsx@...>; AAVSO VSX DIS <vsx-dis@yahoogroups.com>
Cc: Christopher Watson <skygeex@...>
Sent: Friday, June 10, 2011 7:51 PM
Subject: [vsx-dis] VSX "Add reference" is always reyed out

Hello

I just logged into VSX and tried to add a reference to a var.
But the VSX: "Add reference" link is always grayed out with any var I've
looked at.

Is this on purpose that "normal" users cann't add new references anymore ?

Clear skies
Wolfgang

--
Wolfgang Renz, Karlsruhe, Germany