Evolved Massive Stars at Low-metallicity I. A Source Catalog for the Small Magellanic Cloud

Ming Yang, Alceste Z. Bonanos, Bi-Wei Jiang, Jian Gao, Panagiotis Gavras, Grigoris Maravelias, Yi Ren, Shu Wang, Meng-Yao Xue, Frank Tramper, Zoi T. Spetsieri, Ektoras Pouliasis

We present a clean, magnitude-limited (IRAC1 or WISE1 ≤ 15.0 mag) multiwavelength source catalog for the SMC with 45,466 targets in total, with the purpose of building an anchor for future studies, especially for the massive star populations at low-metallicity. The catalog contains data in 50 different bands including 21 optical and 29 infrared bands, ranging from the ultraviolet to the far-infrared. Additionally, radial velocities and spectral classifications were collected from the literature, as well as infrared and optical variability statistics were retrieved from different projects. The catalog was essentially built upon a 1′′ crossmatching and a 3′′ deblending between the SEIP source list and Gaia DR2 photometric data. Further constraints on the proper motions and parallaxes from Gaia DR2 allowed us to remove the foreground contamination. We estimated that about 99.5\% of the targets in our catalog were most likely genuine members of the SMC. By using the evolutionary tracks and synthetic photometry from MIST and the theoretical J−KS color cuts, we identified 1,405 RSG, 217 YSG and 1,369 BSG candidates in the SMC in five different CMDs, where attention should also be paid to the incompleteness of our sample. We ranked the candidates based on the intersection of different CMDs. A comparison between the models and observational data shows that the lower limit of initial mass for the RSGs population may be as low as 7 or even 6 M⊙ and the RSG is well separated from the AGB population even at faint magnitude, making RSGs a unique population connecting the evolved massive and intermediate stars, since stars with initial mass around 6 to 8 M⊙ are thought to go through a second dredge-up to become AGBs. We encourage the interested reader to further exploit the potential of our catalog

arXiv.org: 1907.06717

The ASSESS group roster 2019

Posted June 27, 2019 By grigoris
The ASSESS group during the Supernova Remnants II meeting in Chania, Freece (photo by Dimitra Abartzi)

The ASSESS group during the Supernova Remnants II meeting in Chania, Freece (photo by Dimitra Abartzi)

During the last four days I was busy with the actual materialization of the Astrostatistics Summer School Crete 2019, which took place at the University of Crete, in Heraklion (18-21 June 2019). My duties were mainly those of the Teaching Assistant and I contributed with a short presentation of the Random Forests method for classification. Unfortunately I didn’t have the time to post more on this school, so I ended up doing something only today, at the very last day!

In summary this is/was a school for graduate and early-stage post-docs to get a grasp of the modern field of Astrostatistics, which practically means the application of statistics in Astronomy which incorporates also machine-learning techniques. Topics include: Intro to Python and Jupyter notebook, linear regression, classical statistical distribution tests and hypothesis testing, Bayesian statistics, Markov-Chain Monte Carlo, machine learning classification/regression/clustering, time series analysis.

The school is split in “teaching”/explanatory parts (through Jupyter notebooks though where you could also interact and run the examples) and practical workshops, where important hands-on experience with all the tools presented was provided (and hopefully gained!). However, I think the importance lies in the fact that all the material is publicly available through a github repository: https://github.com/astrostatistics-in-crete (including the notebooks with the introduction notes, the exercises in the workshops, and the data). So this is a valuable source both for students of the school, as well as others interested to try and experiment with these tools.

During a session – from a galaxy far far away – at the Supernova Remnants II conference in Chania, Greece 2019 (photo/editing by A. Manousakis).

At the Supernova Remnants II conference

Posted June 5, 2019 By grigoris

Working and supporting the Supernova Remnants II conference in Chania, Greece 2019 (photo by A. Manousakis).

Fixing GPG error “NO_PUBKEY”

Posted March 28, 2019 By grigoris

In Debian, Ubuntu and similar distros that use the APT (Advanced Package Tool – which is a set of tools for managing Debian packages / applications), to update the system you need to run:

sudo apt update

This will read all repositories (as they are listed in /etc/apt/sources.list and under /etc/apt/sources.list.d/) and checks if everything is correct (e.g. if the links are working and these sites / repositories are trusted sources to install from). So by doing this in my system I got the following:

Hit:1 https://repo.skype.com/deb stable InRelease
Hit:2 http://security.debian.org/debian-security buster/updates InRelease
Hit:3 http://deb.debian.org/debian buster InRelease
Hit:4 http://deb.debian.org/debian buster-updates InRelease
Err:1 https://repo.skype.com/deb stable InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1F3045A5DF7587C3
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://repo.skype.com/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1F3045A5DF7587C3
W: Failed to fetch https://repo.skype.com/deb/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1F3045A5DF7587C3
W: Some index files failed to download. They have been ignored, or old ones used instead.

In this case there is an error with respect to Skype. The systems does not have the public key for this package, so it complains and prevents the system from downloading something which is not secure (and something that we want!).
At the same time this means that I didn’t do something correctly when installing Skype (and to be honest … I do not remember what I did!). Anyway, the proper procedure is a two-step process:

1. Add the repository under the /etc/apt/sources.list.d/ as a separate file,e.g. by:

echo "deb [arch=amd64] https://repo.skype.com/deb stable main" | sudo tee /etc/apt/sources.list.d/skype-stable.list

(adding the repository to /etc/apt/sources.list is actually equivalent – the only difference being that you need to edit that file while it is more convenient, especially for automated scripts, to create a new file under sources.list.d/)

2. Then, the second step is to download the GPG public key that verifies the repository. To do that we can simply:

sudo apt-key adv --fetch-keys https://repo.skype.com/data/SKYPE-GPG-KEY

and we will get:

Executing: /tmp/apt-key-gpghome.fD2Z003jib/gpg.1.sh --fetch-keys https://repo.skype.com/data/SKYPE-GPG-KEY
gpg: requesting key from 'https://repo.skype.com/data/SKYPE-GPG-KEY'
gpg: key 1F3045A5DF7587C3: public key "Skype Linux Client Repository " imported
gpg: Total number processed: 1
gpg: imported: 1

(This is similar or better of doing:

wget URL -O - | apt-key add -

or

curl URL | apt-key add ).

This adds the GPG key in the /etc/apt/trusted.gpg file, and now if we try again to update the system we will see no error or warning.

Hint: to see all the contents of the trusted.gpg file just type: apt-key list !

Working with both Python 2 and 3 in jupyter

Posted January 16, 2019 By grigoris

I have followed the pip install approach to add everything that I wanted for Python. Even though I did the same for jupyter when I was starting it (“jupyter notebook”) it would only start the Python 2 kernel, although Python 3 “was there” but not active actually.

After some digging I found that a similar issue existed already (github/jupyter/issue#270 [1]). By doing


$jupyter kernelspec list
Available kernels:
python2 /home/grigoris/.local/share/jupyter/kernels/python2
python3 /home/grigoris/.local/share/jupyter/kernels/python3

we get the locations of the kernels that are loaded. Under each of the above directories there is a kernel.json file. In more detail:

{
"display_name": "Python 2",
"language": "python",
"argv": [
"python",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
]
}

{
"display_name": "Python 3",
"language": "python",
"argv": [
"python",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
]
}

corresponding to Python 2 and Python 3, respectively. The problem lies in the version of python used, as what we see after the ‘”argv”: [‘ line is “python” in both cases. This is ok for Python 2 since this is the default way to invoke it. But not for Python 3, which needs “python3” (by default). So, the first option may be left as it is, but the second needs to change to “python3” to properly point to the correct version. However, this was not working and I found no reason why (especially since “python” and “python3” invoke the proper versions). In any case a robust solution is to provide the full paths, i.e. “/usr/bin/python” and “/usr/bin/python3”.

As I wanted to become even more specific with the versions used I made the following changes:
{
"display_name": "Python 2.7",
"language": "python",
"argv": [
"/usr/bin/python2.7",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
]
}

{
"display_name": "Python 3.7",
"language": "python",
"argv": [
"/usr/bin/python3.7",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
]
}

so now I can use both versions at the same time in jupyter. This is a manual fix to what should have been an automatic process…

[1] For more details see also this link:
https://github.com/jupyter/jupyter/issues/270

Installing Debian on Lenovo Thinkpad Carbon X-1 (Gen 6)

Posted December 17, 2018 By grigoris

It is exciting to have a new machine, such the Lenovo Thinkpad X-1, but the process for setting it up can be a bit tedious. So this is a small guide what worked or didn’t through my small experience in installing Debian linux. [Just for the fun of it I proceeded with the installation of Win which was really easy with all vocal commands! But they wouldn’t live long … ]

BIOS boot

I started by downloading the net/CD image for Debian 9 (‘stretch’) and putting it to a USB key. I plugged the key at the laptop and started the booting process. First problem: even though it could see the USB and it showed the Debian distro it wouldn’t start. I couldn’t figure out at all why up to the point that I noticed that the new hardware has new BIOS technology called UEFI (yes … I hadn’t installed anything for a looong time!). I went to BIOS > Startup > UEFI/Legacy Boot which was ‘UEFI only’ and I changed the CSM Support to ‘Yes’. But this alone was not enough. So, I changed the UEFI/Legacy Boot from ‘UEFI only’ to ‘Both’ [where I think it should be also to put ‘Legacy only’ if you plan to run on Linux only, but if Win are necessary then leave both].

Debian installation

Then the USB key would finally load and the installation could start. With the graphical installation of Debian the screen goes blank after some time of inactivity, which you can correct with a small movement of the mouse. But since I didn’t have any mouse connected I though that something was wrong. It took me a few iterations before I understand that, which I find ridiculous when you install an operating system. I think that the monitor should be on at all times! The installation went on without any other issues. After logging in the new system, I updated all packages.

Trackpoint/Trackpad issue

At the beginning the trackpad (touchpad) could work with some lag. The trackpoint didn’t work at all but I didn’t pay any serious attention to that. I installed the wifi driver (firmware-iwlwifi, for Intel chips) and after that the touchpad wouldn’t work at all. This is a known problem and many solutions are offered (updating to latest kernel 4.18 and to Debian testing didn’t work). However (and after some iterations of the installation process) I finally went to BIOS > Config > Keyboard/Mouse > Trackpoint and I ‘Disabled’ it. That way the touchpad works without any issue. [At this point it is not so urgent for me to fix this, but I will come back in the future].

Suspend mode

There is a know issue that certain BIOS version have serious problems to recover when suspending the laptop. I learned that the hard way: after suspending the laptop when I was trying to put my password over and over again, as every time it would accept only a few characters before it accepted that raised errors of incorrect password. I had to brutally shut it down (pressing the power button) but for whatever reason the x-server would start. So I had only text access and I couldn’t restarted it (of course I may have missed some more appropriate approaches). Anyway, I re-install Debian from scratch. In order to solve that I needed to update the BIOS.

BIOS update with fwupd

There is a new easy way to update firmware and BIOS through Linux by using the fwupd. After the fresh installation I set this as my first target before I install anything else. fwupd was at Debian repository so it was simply to install it. And the instruction are really easy to follow. Only do ‘fwupdmgr refresh’ to get the latest metadata for you firmware. But at this point it was failing to connect to the webpage (error message: “Failed to download https://s3.amazonaws.com/lvfsbucket/downloads/firmware.xml.gz.asc: Not Found”). The issue (Debian bug #912414) was simply a wrong site, which was easy to fix by going to the config file “/etc/fwupd.conf” and replace: “DownloadURI=https://s3.amazonaws.com/lvfsbucket/downloads/firmware.xml.gz” with the new site: “DownloadURI=https://cdn.fwupd.org/downloads/firmware.xml.gz”. That should do the work, right? NO! Because the version of fwupd installed in Debian 9 is 0.7 and according to Richard Hughsie: “LVFS will block old versions of fwupd for some firmware […] The ability to restrict firmware to specific versions of fwupd and the existing firmware version was added to fwupd in version 0.8.0. This functionality was added so that you could prevent the firmware being deployed if the upgrade was going to fail, either because: i. The old version of fwupd did not support the new hardware quirks, ii. If the upgraded-from firmware had broken upgrade functionality. Then, let’s upgrade fwupd by upgrading (at the same time it would be nice to have a fully fresh new system) and I switched the repositories to Debian 10 (testing, named ‘buster’), upgrading also the Linux kernel from 4.9 to 4.18. And indeed the fwupd now was working! Almost…

BIOS update with USB key

I run fwupd to get the latest BIOS version but it refused. The installed version was 1.25 while only those >1.27 are upgradable with fwupd. Now the only solution is the classic one, i.e. download the last Thinkpad BIOS update (bootable, for Windows) and install it directly from a USB. After having downloaded the .iso image I followed the instructions by Vivek Gite (with most important part the video showing what to do during the actual BIOS installation).

[In brief, using the El Torito boot image extractor (debian package name: genisoimage) do the following:
geteltorito -o bios.img n23ur13w.iso
sudo dd if=bios.img of=/dev/sdb1 bs=1M

Take care that you know exactly which device is the USB key you are going to write to, else you are going to delete data!
Then reboot and enter BIOS and boot from the USB. Select option 3 to verify that you have the right model (in case you press something and you cannot cancel just retype the model number) and then press 2 to start the actual BIOS update. This will run some things now and then when you reboot it will continue before it shows the booting screen.]

Crossing fingers and … booting again! phew… everything is working and indeed I have now the latest version (1.34).

As a (much) later version of the BIOS it should have fixed the issue with suspending mode. Did it work? So far I have experienced any critical issues. What I did noticed though is that that I could feel it a bit hot when suspending. I was going through the BIOS setting and I discovered that there is an option now with respect to the sleep state (I don’t know if it was present in the previous version): Config > Power > Sleep State, which has two options ‘Windows 10’ and ‘Linux’. I obviously picked the last one to optimize the performance and I think it is working now.

Python pip

Finally, the time that I would actually install what I need to start working has arrived! Since Python2.x and 3.x exist I was going to use pip only to install all necessary packages. I installed pip for both Python versions from the distro repositories. Checking the pip site I saw the following recommendation: “Ensure pip, setuptools, and wheel are up to date, by doing: python -m pip install –upgrade pip setuptools wheel”.

Well, first of all … DON’T DO IT! I missed the obvious warning sign above:

Warning
Be cautious if you’re using a Python install that’s managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use python get-pip.py –prefix=/usr/local/ to install in /usr/local which is designed for locally-installed software.

By default the pip version provided by the Debian repositories is 9.x. When I did this upgrade I got the latest version of 18.x and I went on to install numpy, scipy, matplotlib. But when I started python to try out the installation nothing was working! Even worse:

pip install astropy
Traceback (most recent call last):
File "/usr/bin/pip3", line 9, in from pip import main
ImportError: cannot import name 'main'

What is going on now? Apparently is it not a good idea to upgrade with pip a system installation of pip, as then pip gets confused of which version to use exactly and, even worse, some scripts managed by apt may break (see e.g. the discussion in github issues #5447 and #5221). So the two important advice here are:
1. upgrade/install under user (with –user)
2. avoid running pip with sudo (which may affect root accessed files)

I found various ways to fix this over the internet, but I opted for a more … brutal way. I noticed that when installing Python packages from the repositories of the distribution everything is installed under the /usr/lib/python*.*/dist-packages/ while pip puts everything under /home/user/.local/lib/site-packages/. So, the idea was to remove (manually delete) everything under these directories. Then I could re-install pip and the Python packages and it should be clean from all errors. I did that but I continued to get errors, but probably that was because I didn’t re-source the terminal (so paths to the previous packages and scripts were still active). After a reboot I found everything working fine. [One note: after a fresh installation everything is new, such as the content of $PATH. When I installed jupyter and tried to run it I got an error “command not found”, obviously because I forgot to update the $PATH to include the ~/.local/bin/ directory, where binaries from pip are stored.]

 

Other resources

The above is a personal (certainly not the wisest) experience to install Debian 9/10 (stable/testing) to Thinkpad X-1. There are also more thorough and knowledgeable guides out there (which I have to check also for other issues), such as:
–> Installing Debian On Thinkpad X1 Carbon 5th Gen (previous generation)
–> Lenovo ThinkPad X1 Carbon (Gen 6) by Arch linux

New paper on rho Cas and its recent outburst in 2013

Posted December 11, 2018 By grigoris

A new outburst of the yellow hypergiant star Rho Cas

Michaela Kraus, Indrek Kolka, Anna Aret, Dieter H. Nickeler, Grigoris Maravelias, Tõnis Eenmäe, Alex Lobel, Valentina G. Klochkova

Yellow hypergiants are evolved massive stars that were suggested to be in post-red supergiant stage. Post-red supergiants that evolve back to the blue, hot side of the Hertzsprung-Russell diagram can intersect a temperature domain in which their atmospheres become unstable against pulsations (the Yellow Void or Yellow Wall), and the stars can experience outbursts with short, but violent mass eruptions. The yellow hypergiant Rho Cas is famous for its historical and recent outbursts, during which the star develops a cool, optically thick wind with a very brief but high mass-loss rate, causing a sudden drop in the light curve. Here we report on a new outburst of Rho Cas which occurred in 2013, accompanied by a temperature decrease of ~3000 K and a brightness drop of 0.6 mag. During the outburst TiO bands appear, together with many low excitation metallic atmospheric lines characteristic for a later spectral type. With this new outburst, it appears that the time interval between individual events decreases, which might indicate that Rho Cas is preparing for a major eruption that could help the star to pass through the Yellow Void. We also analysed the emission features that appear during phases of maximum brightness and find that they vary synchronous with the emission in the prominent [CaII] lines. We conclude that the occasionally detected emission in the spectra of Rho Cas, as well as certain asymmetries seen in the absorption lines of low to medium-excitation potential, are circumstellar in nature, and we discuss the possible origin of this material.

arXiv.org: 1812.03065