As we've noted before, Adobe moved to a licensing model where all usage of their software is tied to an Adobe ID. For most SSCC members, your Adobe ID can be your UW NetID. For student workers and emeriti, you'll need to make a free Adobe account.
If you start Adobe Acrobat or another Adobe program and get a window that says Sign In Required, click on Sign In Now. You'll then get a window that says Sign In. Type your NetID@wisc.edu email address in the line directly below that, but don't put anything in the Password line. Then click on the Sign In button. You'll be taken to a UW-Madison login page where you can give your NetID and password and authenticate with Duo. Most people will only have to do this once on each computer they use.
Unfortunately, the new licensing forbids us from installing Adobe software on Winstat other than Reader. If you need to create or edit PDF files on Winstat, use the Adobe Document Cloud (i.e. web-based Acrobat). If you need other Adobe software you’ll need to install it on your computer or come to the 4218 lab. To install Adobe Software on an SSCC-managed Windows computer, first open Software Center and use it to install Adobe Creative Cloud Desktop, then use Adobe Creative Cloud Desktop to install whatever Adobe software you need.
There are some rare exceptions and special cases. If you have trouble signing into Adobe software, contact the Help Desk.
The spread of Coronavirus Disease 2019 (COVID-19) raises the possibility that many SSCC members may need to work from home for extended periods. SSCC has a variety of tools for remote access that can make working from home productive:
Working From Home and Other Remote Locations describes the options and will point you to the appropriate instructions for using them. We recommend deciding what tools you'll use and trying them out now while you can come to the Help Desk for assistance if you run into problems.
We have reviewed our readiness for a pandemic, and our only concern is that if a large fraction of our members tried to use Winstat at once it might be overwhelmed. So we suggest logging into your office computer if it will do what you need—but this requires some setup by SSCC Staff. If you anticipate needing remote access to your office computer, we suggest contacting the Help Desk now to get it ready to go.
We always recommend leaving your computer so it can run updates and such overnight—it will go into sleep mode and use minimal electricity—but it's especially important right now. One thing we can't do remotely is turn your computer on for you so you can use it from home.
Beginning on April 1st, Doug Hemken will switch to working for the SSCC half-time. Doug has had a part-time position with a flexible schedule for many years, but with this long-planned transition he will be taking off more time to pursue other projects. This will sometimes take him out of the office for a week or more, so if you need his help in particular, do not wait until the last minute to contact him.
We are well into the process of hiring a replacement for Mark Banghart and should have that position filled in April so we'll be back to having three statistical consultants. Also, once the other new positions are filled Russell Dimond will hand off some responsibilities to them (like SSCC News) in order to have more time for statistical consulting.
FiveThirtyEight recently had to report that they had found an error in their model for Democratic Presidential Primary: the demographic model they had created to predict candidate strength where there was little or no polling data was not actually being used. Why? Because they had forgotten that local macros in Stata really are local.
The demographic model was implemented in a separate do file that was called by their master do file, which is a great way to organize complicated code. But it returned its results, or tried to, by storing them in a local macro. The trouble is, local macros are "local" to the do file that creates them, meaning that every do file has its own set of local macros and no do file can access the local macros created by another do file. This is usually a good thing, especially given that most Stata commands are actually do files: it lets you create a macro called 'x' without worrying that another do file might also create a macro 'x' and overwrite yours. If you want to send information from one do file to another, you need to use a different tool such as estimates store to store results in memory, post to put results in a data set on disk, or global macros.
Note that if you run part of a do file and then another part later, those count as separate do files as far as local macros are concerned. Local macros defined in the first part won't be accessible to the second. Once you start using local macros, you usually need to run your entire do file rather than parts.
R users are more likely to run into the opposite problem. Once you start an R session, anything you run will store the objects it creates in your workspace where they'll remain for the duration of your R session, and any program can access any object. Not only does this mean programs can change each others' objects, when you're working on a program it's easy to accidentally create dependencies like "line 20 only works if you've previously run lines 60-80." At the most recent RStudio Conference Jenny Bryan gave a long talk on debugging in R but her two most important tips were very simple: never save your workspace, so that restarting R will give you a blank one; and restart R often.