Archive for the 'Reference' Category

Finding a Good Research Topic

Miscellaneous, Reference 4 Comments »

A student from China recently asked me about how I got interested in relay selection and started obtaining (publishable) results. Since I have some free time on my hands now, I figured I’d share some thoughts on this topic.

I actually don’t think that the way I got interested in relay selection was the ideal strategy in terms of “finding a good research topic.” Instead, I’ll discuss what I think is a better way of “finding a good research topic.” Note that the following is especially relevant for graduate students researching wireless communications (for the obvious reasons).

It’s fairly common for a new graduate student to be overwhelmed by the plethora of potential research topics. When I was starting work on my masters degree, I wanted to do research involving some aspect of wireless networks, since I felt (wrongly, as it turned out) that all of the good point-to-point problems had already been solved. During the summer of 2004, I worked on beamforming for MIMO ad hoc networks, but that ended up being a major dead end. On a related note, I recently perused my research notebook and found that during January 2006, I was interested in cooperative diversity for OFDM networks (my, how things have changed).

This brings up the key question: how should a new graduate student sort through the morass of potential research topics and come up with a good one? I’ll discuss two potential answers.

One approach is to have your advisor answer this question for you, assuming that you have an advisor. In general, you can assume that your advisor has a strong grasp of the current state of research in wireless communications. This knowledge can help him/her determine a topic for you that is 1) interesting, so you won’t be bored stiff for approximately 5 years and 2) worthy of a Ph.D. dissertation, so you will have made a fundamental contribution of some sort by the time you graduate.

The second approach, which I highly recommend, is to take the initiative. To start off, you should do a significant amount of reading. Survey articles in journals such as the IEEE Communications Magazine and the IEEE Signal Processing Magazine can be valuable starting points for the interested yet relatively inexperienced grad student.

A particularly well-written survey article can provide the reader with a good grasp of “what’s been done” on a topic such as “OFDMA power allocation for relay-based networks” and suggest various open problems that are both interesting and important. When reading through these survey articles, one should also scan the list of references to learn about the key papers (and researchers, so you can bookmark their home pages) in a particular area.

It’s then important to read through these key papers to grasp the nuances of the topic that you’re learning about and ask yourself tough questions along the way. For example, do you understand the (technical) paper that you’re reading? Can you justify all of the authors’ assumptions? Can you re-derive every expression (especially the proofs of key theorems) in the paper? I should note that sometimes papers contain typos/gross errors, so you shouldn’t automatically trust everything you read.

If you want to answer these questions in the affirmative, this is a great opportunity for building your technical background. For example, let’s say that the authors are studying a MIMO wireless system and assume that a two-ring scattering model is being employed. If you don’t know what a two-ring scattering model is, you should obtain a copy of a MIMO textbook such as this one by Paulraj et al. and learn more about channel modeling.

Also, let’s say that you’re reading through this famous paper by Gupta and Kumar, and you’re having trouble deriving some (or all, as this paper is actually quite tricky to understand) of the key results. In this case, you might want to strengthen your graph theory background by taking an appropriate class, such as this one at UT-Austin. You might also want to improve your knowledge of random geometry, and you can check your university library for a helpful book such as this one by Bollobas for more coverage of this advanced topic.

As you read through the key technical papers in the area that you’re learning about, you should think of additional open problems and ask yourself more tough questions. For example, you can ponder something like, “the authors’ assumption of a zero-error feedback channel seems a bit restrictive. From my other reading it’s clear that introducing a channel estimation error at the transmitter would better model a practical system. Maybe I can’t obtain an exact expression for the sum capacity given channel estimation errors, since that seems quite complicated, but can I obtain relatively tight bounds?”

Regardless of the approach that you take in terms of finding a good research topic, it’s crucial that you interact with your advisor during this process. Your advisor, who has worked in either the general area that you’re considering or a related area, can help you determine if the open problem you’re considering is either trivial, worthy of multiple dissertations, or actually reasonable for a dissertation. Note that by adopting the second approach I discussed above, your ability to have meaningful dialogue with your advisor during this process is enhanced. In particular, you can evaluate your advisor’s suggestions and converge on a reasonable topic more quickly; this is especially important if your advisor has not worked in the general area that you’re considering.

That’s all I had to say on this subject, at least for now. I welcome comments, especially from my group-mates on this issue of “finding a good research topic.”

Finite-SNR Diversity-Multiplexing Tradeoff

Reference 2 Comments »

After my post on the diversity-multiplexing tradeoff, which seemed to create confusion instead of alleviating it, Prof. Heath asked me to clarify the finite-SNR diversity-multiplexing tradeoff proposed by Narasimhan in [1] (pdf). The previous explanation of the Zheng-Tse DMT really simplifies the explanation of the Narasimhan DMT. If you understood the previous post (in the rest of this post I will assume you didn’t), then the finite-SNR result simply defines diversity as the slope of the outage curve at a given SNR. If you have the 3-D plot of outage versus SNR and R, then fix r. Then, for each SNR, the DMT curve is given by (d,r,SNR), where d is the slope of the outage curve at SNR. There is a little bit more to it, so keep reading even if you understood that.

Now, I’m back to assuming you didn’t understand the previous post. This is a safe assumption, as I feel I didn’t explain it very well. We can all agree, I think, that in an ideal world with real-rate constellations, we could express the probability of outage as a function of both SNR and R. Again, R is simply the spectral efficiency of the signaling mode. For instance, if we are sending two streams of 16-QAM, R=8.

So we have this P_out(R,SNR) expression. We’re going to imagine this curve plotted in three dimensions. First, imagine a normal 2-D plot of outage versus SNR for a fixed R. Suppose, for instance, R = 1; that is, we’re sending BPSK using the Alamouti code. Simple, eh? Now, bring in the third dimension of the plot, pointing toward you. Thus, the x-axis is SNR in dB, the y-axis is R, and the z-axis is outage probability.

We can imagine that as R increases, the curve becomes more spread out in the SNR dimension. Intuitively, at any given SNR, a larger rate means a higher probability of outage. It’s important that you can see this before moving on. The 3D figure from the previous post might help.

Again, our three axes are SNR, R, and outage. For a moment, let’s forget about the probability of outage and focus on the relationship between SNR and R. For a fixed number of transmit and receive antennas (Nt and Nr, respectively), MIMO information theory tells us that R is always less than or equal to m*log2(1+p), where p is the per-stream SNR at the receiver, and m=min{Nt,Nr}. The figure below plots this upper bound on R versus 10*log10(SNR) for m=1,2. The red line corresponds to m=2, and the blue line corresponds to m=1. We also plot the lines m*log2(SNR) for m=1,2. At SNR > 15 dB, the m*log(SNR) and m*log(1+SNR) lines virtually overlap for respective m.

Now, remember these are upper bounds on R; in practice, we will not achieve them. However, for a particular signalling strategy, we can plot our R on this plot. For any strategy that does not adapt the rate with SNR, our rate plot will be rather boring. It will be a step function with transition at the SNR below which we cannot reliably communicate at that rate (assuming no channel coding).

Observe that as SNR grows arbitrarily large, the ratio between our fixed rate R0 and the SISO capacity (the blue curve) will become arbitrarily small, regardless of what R0 is. This ratio, at any particular SNR, is the definition of multiplexing gain given in the finite-SNR DMT. Let me repeat this for clarity. For any adaptive signalling strategy, we can plot its rate as a function of SNR. The finite-SNR DMT multiplexing gain at a given SNR is defined as the ratio of our rate to the SISO capacity at that SNR.

We see right away how this is a generalization of the Zheng-Tse DMT. They define multiplexing gain as the limit of the ratio between our R curve and the linear magenta curve as SNR goes to infinity. If we do not adapt with SNR, this ratio becomes arbitrarily small, such that its limit is zero (r = 0). For any finite SNR, however, this ratio is strictly nonzero.

Recall for a second that, in my previous post, I defined the multiplexing gain as the derivative of R with log(SNR). Strictly speaking, this was inaccurate. It is only valid at high SNR and if R is linear with log(SNR). In practical systems, R will be nonlinear in SNR.

Now, back to our figures. We’ve plotted R as a function of SNR, and defined the multiplexing gain as the ratio between our R and the SISO channel capacity. These curves on this 2D plot, however, are surfaces when extended into the outage dimension. This is very important to visualize. Think of the line y = x in two dimensions. Extending this equation to three dimensions results in a plane perpedicular to the y-x plane. We can do the same with our R-SNR plots.

So now, to recap, in our minds we have a 3 dimensional space. The dimensions of this space are x = SNR, y = R, and z = Probability of outage. In this space we have plotted probability of outage for our signalling mode (say, for example, the Alamouti code). Now, we have a surface sticking up out of the x-y plane that represents how we plan to vary R with SNR. The intersection of these two surfaces is a curve. That curve is the probability of outage curve for our signalling mode and adaptation strategy.

Now we define diversity as the negative slope of that curve at any given SNR. Again, this is easily seen as a generalization of Zheng-Tse, since their diversity is the negative slope of that curve as SNR goes to infiinity.

Then, the point on the finite-SNR DMT curve is the triple (d,r,SNR), where again r is the ratio of our R to the SISO capacity at the given SNR.

I hope that made sense, because that’s about it. I’ll now talk about some intuition.

First, since r is the ratio of our R to the SISO capacity, r > 0. The limit r = 0 doesn’t make any sense, but we can approach it arbitrarily closely at any finite SNR. Thus, we can’t really achieve the full diversity gain of the channel at finite SNR.

Further, since our R will be strictly less than capacity, the ratio of R to the SISO capacity will always be less than the ratio of the system capacity to the SISO capacity. Effectively, we won’t achieve the full multiplexing gain of the channel at finite SNR, either.

Finally, we note what this finite-SNR DMT can tell us that the infinite version cannot. By taking the limit of the ratio of R over the SISO capacity as SNR goes to infinity, we’re effectively saying R is a line of slope r. This is why I could fudge it and say r = dR/dlog SNR for the infinite-SNR DMT but not for the finite-SNR DMT. By not taking this limit, the math becomes all but intractable, but we can now make r nonlinear! It can increase (or decrease) however we wish, although it will be upper bounded by the ratio of our capacity to the SISO capacity.

Also notice that, if we don’t adapt with SNR, r is still greater than zero for any finite SNR. For example, again, say R = 1. At SNR=10dB, r will be approximately 1/3, and we’ll say d is some d0. At SNR = 20 dB, r is approximately 1/6, and d will be some d1 > d0 (the slope of any outage curve is monotonic decreasing with SNR). Thus, as SNR increases, on the DMT curve, we move up (d increases) and to the left (r decreases).

So, it seems the major thing Narasimhan’s finite-SNR DMT tells us is how quickly a certain strategy approaches the optimal Zheng-Tse DMT. Two strategies that both achieve the optimal DMT curve will likely have different outage curves, and will thus approach the optimal curve at a different rate. The strategy that approaches it quicker will have a smaller outage probability above some unknown crossing point (which may not even exist; one strategy might always be better than the other in terms of outage).

This motivates our last point. The finite-SNR DMT still doesn’t give crossing points or tell us precisely when to switch from one mode to another. It can give us an estimate of where to switch, however. If two outage curves cross each other, then at some SNR smaller than the crossing-point SNR, the higher curve started decreasing quicker than the lower curve; that is, its diversity became higher than the other’s. Since d is nondecreasing with SNR (for any sensible r), this switch will only happen once.

Take, for instance, Alamouti coding with 16-QAM versus spatial multiplexing with 4-QAM using an ML receiver. Here our model assumes 2 transmit and 2 receive antennas. The probability of vector symbol error (okay, not outage, but the same concept applies) for these two strategies is below.

For the infinite-SNR DMT, r = 0, and the best strategy is always the Alamouti code, which achieves d = 4, while spatial multiplexing with ML receiving achieves d = 2.

For the finite-SNR DMT, r is varying with SNR, though it varies equally for both strategies. Observe that the slope of the error curve of the Alamouti code is flatter at low SNR than the slope of the SM-ML curve. Thus, at low SNR, d(Alamouti) < d(SM-ML).

At around 10 dB, the slope of the Alamouti curve becomes steeper than the slope of the SM-ML curve. Thus, at apprximately 10 dB, d(Alamouti) > d(SM-ML). There is a crossing point in their DMT curves around 10 dB and r approximately 4/3. Note, however, that the error curves don’t cross until approximately 17 dB. Quite a gap. Since, to find the finite-SNR DMT, you must take the derivate of outage term approximations, however, you probably have a decent estimate of the outage terms and can directly calculate crossing points, if that is what you’re interested in.

In summary, the DMT gives us intuition about the outage curves for different signalling strategies. In particular, the DMT curve does not tell us there is a tradeoff in how we use an extra antenna pair given to us, but instead a tradeoff in how we use extra SNR given to us. We can use extra SNR to increase our rate, or decrease our outage probability. This is the fundamental tradeoff.

The Diversity Multiplexing Tradeoff

Reference 6 Comments »

Note 1: You may want to check out my followup post on the diversity-multiplexing tradeoff. I think it’s a bit clearer than this one.

Note 2: You need to click on the figures to view them.

I’d like to share some intuition on the diversity-multiplexing tradeoff (DMT) given to me by Rahul Vaze. This way of looking at it really makes clear what its values and limitations are.

The first step in the intuition is to note the definitions of diversity and multiplexing. Here, multiplexing is not spatial multiplexing. That is, it is not the number of parallel streams being transmitted. This is one place where a lot of people seem to get confused, because strategies such as spatial multiplexing with maximum likelihood detectors can use the maximum available degrees of freedom in the channel while achieving a diversity gain, whereas the DMT shows that maximum “multiplexing” gain will be at the expense of all diversity.

To understand what multiplexing means here, we first define rate R to be the number of spatial streams being transmitted times the number of bits per transmission per stream. Thus, if we are sending N_sstreams of M-QAM, R = N_s \log(M) bits per transmission. Note that as SNR increases, we can increase M, but we cannot Ns above its maximum level. For this R, and for a given detection strategy, there is a probability of outage curve that resembles the figure below. At high SNR, the log-log curve is a line with slope -d, the diversity order of the strategy.

Diversity-Multiplexing Tradeoff

Now imagine we are at some SNR g1, as shown, with outage probability p1. Suppose the SNR increases to g2. If our constellation size does not increase at all, we are sending at the same rate, and the outage curve remains as shown; we are now operating with outage probability p2. If for every SNR increase, we keep sending the same constellation, and choose to operate at a lower outage probability, at high SNR we will be benefiting from the full diversity gain of the strategy.

We now define multiplexing gain as r = \frac{dR}{d\log (SNR)}. Recall our definition of R = N_s \log(M), which does not readily depend on SNR. However, we can choose to make M depend on SNR by using continuous-rate (ideal) adaptive modulation. So M = f(SNR). In the previous example, M = M0, which was independent of SNR, so r = 0. This corresponds to the y-intercept of the DMT curve where the maximum diversity (of the strategy, not necessarily of the channel) is achieved.

It is now natural to ask “what is the fastest achievable rate of change of M with SNR“? Observe that log M is the number of bits per transmission over a SISO link. By Shannon’s formula for the Gaussian channel, log M \le log(1+SNR). Therefore, \frac{d\log M}{d\log SNR} \le 1. So what happens when we let \frac{d\log M}{d\log SNR} = 1 , i.e., when we allow our constellation to grow linearly with SNR? We see that now r = N_s. This corresponds to the x-intercept of the DMT curve. But why is diversity zero in this case? The answer to this will give us intuition about all the other points on the DMT curve.

First we observe that, for a fixed transmit/receive strategy, the probability of outage curve is a function of both SNR and R. For simplicity we usually calculate, and plot, the outage curve for fixed R. This is also because, in practice, only integer-rate constellations are used, so an outage plot as a function of R would be discrete in R. However, if we pretend we can send real values of log M (that is, we have constellations of order M, where M is not an integer power of 2), we can plot outage as a continuous function of R. This is still not done, because 3-D plots are difficult to observe on paper, and are generally unnecessary. Instead, on a single 2-D plot, we take cross sections of the curve for fixed values of R.

So in the figure below I’ve drawn some possible outage curves for a fixed strategy as a function of SNR and for different R. Suppose again that we are operating with R = Ns log M0 at SNR g0 with outage p0. This time, however, when g0 increases to g1, we increase M0 to M1 linearly with SNR. Thus, we have kept the gap between our rate R and capacity C constant, and the outage probability will be unchanged.

Diversity-Multiplexing Tradeoff

Adapting the rate with SNR effectively results in a new outage curve that is not a cross section of the general outage curve using a plane parallel to the R = 0 plane, but instead is a cross section using a plane with slope r in the R dimension. I hope the figure below (click for a larger version) explains it better than I can with words.
An example of outage as a function of both R and SNR

Now this new outage curve is for a fixed r. For this fixed r, the log-log outage probability curve will be linear with some slope at high SNR, and we call this slope -d(r). This pair (r,d(r)) is one point on the DMT curve. As we vary the R-slope (r) of the cross-section plane in the figure above, we observe different d(r). Obviously, the steepest slope will occur when the plane is perpendicular to the R-plane, or when r = 0. Correspondingly, if this cross-section plane is such that outage is flat, then r is along the line of constant outage (color in the figure above) and d(r) = 0.

Because this tradeoff curve is only relevant asymptotically with SNR (via the diversity gain), it has no application to adaptive signaling strategies. For instance, if at SNR g1 you decide to switch from, say, the Alamouti code to spatial multiplexing, this switch is completely lost in the DMT tradeoff. The tradeoff only tells you how fast you can scale the rate of a fixed strategy relative to how fast capacity is changing at high SNR and still achieve a linear log-log decrease in outage probability.

Slide template using LaTeX

Reference 1 Comment »

Hi all, my first post here.

In my attempt to simplify the process of creating slides, especially with equations, I have created a WNCG template slides using HA-prosper. This package will allow you to create nice looking slides using our best friend, LaTeX. I am posting this here in case anyone would like to reuse this template.

You can download the working package here.
And the HA-Prosper manual here (for misc tweaking).

The package contains:

  • Core files
    • WNCGTemplate.tex - Main TeX file
    • HAPWNCG.sty - Style file
    • UTECElogo.eps - UT ECE logo
    • WNCGLogo.eps - WNCG logo
  • Supporting files for this example
    • bf_mimo.eps
    • Research.bib
    • IEEEtran.bst
  • WNCGTemplate.pdf - Precompiled PDF slide

The compile process follows the usual procedure.

  1. LaTeX it once to catch the references
  2. Run Bibtex
  3. Latex twice to get the references
  4. dvips
  5. ps2pdf

I have not found a way to compile in one step using pdflatex. Please let me know if you find a way :-)

One catch about using HA-prosper is that it includes the logos for each page, thus creating a pretty large PS/PDF file. This is documented in HA-prosper manual and there seems to be no work around at this point.

I hope you find it useful. Any comment/suggestions for improvements or sarcasm are welcome!

IT++ for Mac OS X and Linux

Reference 4 Comments »

Many of you may be aware of the IT++ C++ library of information technology related functions.

IT++

IT++ includes vector and matrix functionality much like Matlab as well as many communications related functions (coding, interleaving, modulation, etc). Of course you’re still programming in C++ so it’s definitely more painful than Matlab, but if you have any computationally intensive functions that you’d like to use for simulation purposes, this package may be useful to you. The Hydra multihop prototype makes use of this library for it’s vector/matrix structure.

Tux.jpg

The installation of IT++ for use with Linux distributions is a fairly straightforward affair:

  1. Using the link from the IT++ site, download the latest IT++ source.
  2. Follow these instructions for making the source.

If you are using the Gentoo Linux distribution, the package manager (emerge) will do steps 1 and 2 for you. When compiling C++ programs using IT++ libraries, you must consider the appropriate syntax for proper linking.

Recently, I had the desire to install IT++ on my intel Mac OS X laptop. Unfortunately, there is little documentation on how to get this working. It took me a while to tweak the settings, but I finally got it to work. Here are some hints:

  • Use fink to install FFTW and ATLAS.
  • Using the x11 terminal keep the default prefix (/usr/local) when executing the configure script. Other locations will make header inclusions messy.
  • When you use fink to install the FFTW and ATLAS dependencies (which optimize matrix/vector and FFT computations), you must add this to the library and include paths. For example, you might execute:
    export LDFLAGS=”-L/sw/lib”
    export CPPFLAGS=”-I/sw/include”
    ./configure
  • Before executing the configure script, you need to point to doxygen, dvips, and latex (I’m not really sure if you need all of this). The problem is, the installation looks for these programs in the root directory, and if you’re using fink (again, I recommend this) these programs are installed in the /sw/ directory. I created links for all three of these programs. For example
    sudo ln -s /sw/bin/dvips /usr/bin/dvips

    creates a symbolic link in the root to the fink-installed dvips program.

A follow-up to Dr. Ahn’s Post on Self-Plagiarism

Reference 1 Comment »

Dr. Ahn has circulated an email in our group recently regarding the IEEE’s policy on reusing material from prior publications. I found that the material in this document by Douglas Verret was important enough that it shall be highlighted here. A few of the key points:

  1. The Publications Products and Services Board (PSPB) operations manual is available here.
  2. “Authors should only submit original work that has neither appeared elsewhere for publication, nor which was under review for another refereed publication.”
  3. “Two specific features have been identified that distinguish regular papers in the TRANSACTIONS from conference papers. First, regular papers undergo a rigorous review process that marks them as having met or exceeded accepted standards of scholarship.” “Second, regular papers by definition are less cryptic and condensed and therefore offer better clarity, more complete justification of findings and more detail overall.”
  4. “There is no value to the readers in republishing verbatim an extended abstract that has appeared or will appear in a public archive in either paper or electronic form.”
  5. “Of particular importance are a few guidelines that are mandatory. They are: 1) the conference paper must be cited in the enhanced version; 2) the author(s) must explain in the introduction specifically how the conference paper has been enhanced; 3) if the conference paper is not available in Xplore®, the authors must provide an electronic or paper copy of the conference paper; 4) if IEEE does not own the copyright for the paper and figures, the author(s) must obtain the appropriate permission for IEEE to republish them.”
  6. “It is anticipated that at least a third of the enhanced manuscripts contain relevant material that was not in the conference paper.”
  7. For journal papers, a more complete reference list and extended introduction compared to conference papers is suggested.
  8. If information in a paper is not unique, refer to work that explains the relevant topic such that space is not wasted.
  9. Use the questions asked in conference talks to better approach the journal version of a topic.

Personally, I think much of this is obvious, but we’ve all read journal and conference papers that are virtually indistinguishable in terms of content. I think this is something that all reviewers need to take to heart. It’s not a given that if a topic is good then the paper should be published. We all have to keep in the back of our minds: “What is valuable in this paper?” If a figure, discussion, or analysis in a paper doesn’t lend insight, it is our responsibility as the reviewer to cut it out. Perhaps this will cut out journal papers that are just “conference papers with extra simulations.”  What are your thoughts?

ArXiv Preprint Repository

Reference No Comments »

ArXiv (http://arxiv.org/) is one of the best sites for publicly presenting your work before publication. Arxiv provides a copyright to your original documents as soon as you upload it to ArXiv, which means that you can prevent somebody from plagiarizing your original ideas after opening them to the public. While this concept is very fascinating, uploading to ArXiv is somewhat painful. You must follow their strict uploading procedure. Below I will present this uploading procedure. The manual is available at http://arxiv.org/help/

  1. First of all, you must have an I.D. in the Arxiv site to upload you paper. Please make your own I.D. in IT category of the Computer Science field.
  2. Go to http://arxiv.org/submit directly and you’ll see Submit Form. Just fill the general information about your paper into the blanks.
    • The main blanks you have to fill in are as follows.
      1. Paper Title
      2. Authors’ Names
      3. Comments where you should write down the paper information such as paper length, # of figures and submission information.
      4. Abstract
    • If you’re done filling in this form, you’re ready to upload your paper.
  3. Before uploading it, you have to have a *.zip file that compresses your original LaTeX file and the figure files included in the paper. The ArXiv system finds your LaTex file in the zip file, compiles it and coverts to three different versions of the paper including PDF, PS and DVI.

The biggest problems are related to the figures. In my case I usually use Photoshop to make EPS files though it doesn’t work in the ArXiv systems. If you try to make the figures in other ways, you may have success in uploading your paper. If you have the figure problem, then you can get some help available at http://arxiv.org/help/faq/mistakes#psbad and http://arxiv.org/help/faq/. If you still have some problem for uploading, please stop by my office and let’s try to solve your problem together.

Reviewing a Journal Paper - Guidelines

Reference, WSIL Procedures 6 Comments »

It is that time of year again. No, not spring, its the beginning of the semester. As the semester is kicking in, so does the ever present flow of journal paper review requests. I get 2-3 review requests a week and often end up delegating them to my students, when they are of mutual interest. In this summary I provide some details about the reviewing process for journal papers.
Why should you review a paper? In brief, reviewing a paper provides:

  1. A window into the review process. When you review a paper you read a manuscript critically, and hopefully start to realize potential criticisms of your own manuscript.
  2. A privileged insight into state-of-the-art in research, new research tools, methods, etc. Remember that reviews are confidential - nothing learned can be used until the paper is published. If you find something new, write it down and put it away until the journal or conference version appears.

Reviewing is a duty of every active researcher. If you submit a paper to any journal, you are, karmic-ally speaking, obliged to review one or more papers in return. Note, this does not mean that you are obliged to respond positively to every review request. To be fair to the authors and editors, you should only accept papers that you can confidently review, either on topics you know or are willing to get to know. Feel free to say no if you have a good reason. Keep in mind that you should try to review papers in your research area as a means of keeping in touch with the research world.

Reviewing also gains visibility. Editors are potential sources of employment, for academic jobs, or reference letters. Writing good detailed reviews may lead to a postdoctoral position, job, or collaboration later one.

Now the hard part, actually reviewing a paper. This is a matter of personal taste. Many may not agree with my suggestions but, as an editor, this is what I would like to see from a reviewer.

Review guidelines

  1. A serious review should be at least 1-2 pages of single spaced text. Longer is generally better. In extraordinary cases, there will be a really good paper and you just can’t find enough to complain about. In most cases though there will be many issues.
  2. Your review is preferably written in plain text and pasted into the appropriate manuscript central window (or sent to the editor in an email). You can also use a pdf but sometimes pdf files have tags that can identify you. If possible avoid pdfs and this pitfall of being identified.
  3. Plan to spend anywhere from 2 hours - 2 days on a paper review. It depends on how well you know the area. If you don’t know the area you may have to do some background reading to see if the proposed research is novel.
  4. Always do your own check for novelty. Often authors do not cite important papers. Do not rely just on the list provided by the authors, especially if it is quite thin, i.e. less than 20 references.
  5. The most important ingredient of a review is critical insight. You must demonstrate a clear understanding of the paper and form a strong opinion. Your written review must reflect this.
  6. Typical composition of a review
    • Summary of the review. In this case you summarize the review in your own words and provide a recommendation. Typically this includes a summary of the key contributions of the paper (your opinion of the key contributions, not a restatement of the abstract) and some justification for your recommendation. Recommendations include
      • Accept - This is super strong and should only be applied to absolutely stellar papers on the first round of reviews. Can be used on subsequent rounds if paper has evolved to an acceptable level.
      • Minor revisions - This is quite strong. Usually used for the case where the technical content is sound but there are some issues that you believe can be addressed by the authors. Paper is typically accepted after minor revisions.
      • Major revisions - This is weak. Used for cases where you have some concerns about the manuscript that you don’t know if can be addressed, or if you have a lot of comments and you want to make sure they are all addressed.
      • Reject - This is the worst outcome for the authors. Used in cases where there are major flaws in the paper or it requires a major revision. Sometimes rejected papers are (and should be) resubmitted. Other times not.
    • List of issues in the paper with discussion. Typically this will take the form of a bulleted or numbered list of paragraphs. Numbering helps the authors respond to your comments in their reply. In each of these cases, I suggest that you include a summary of the issue and some discussion. For example “I don’t believe the derivations in equation (XX). A previous paper [ref to paper] showed that …” Examples of major issues include
      • Problems with writing
      • Problems with derivations
      • Errors in equations
      • References missing
      • Simulation results missing
      • Comparisons missing
      • Paper organization needs improvement
      • Problems with references (number, formatting, etc)
    • List of less critical concerns. This includes typos, formatting issues, grammatical errors, etc.
  7. Be careful to maintain your anonymous status when you review a paper. Be careful about citing your own work - it is often a dead giveaway. It is tempting when you read a paper related to your research but be very careful. It is especially important not to cite your own preprints, or preprints of others, that are not widely available on the web. I have had several excited reviewers cite many of my papers in their reviews for me. It puts me in an awkward position. Cite what is relevant. Only cite your paper if absolutely essential and then with some other papers as well.
  8. Avoid conflicts of interest. Never review papers co-authored by your advisor. Be careful about reviewing papers of close collaborators. If you can’t provide an unbiased review then you should pass on it, or at a minimum disclose to the editor.
  9. Sleep on the review and reread before submitting. Even if the paper is quite bad, don’t be too harsh. A review that is offensive to the authors is just that - offensive. It makes it harder for the editor and shows a lack of refinement. If the paper is poor, simply document this as best you can. Do not get emotional.
  10. Submit your review on time. It helps authors and reviewers if you can submit the review in the timeframe agreed.
  11. Check as much of the paper as possible. It is hard to rerun the simulations yourself but you should check the math in the paper and all other statements. Often steps are missing, proofs not quite correct, etc. Check everything. If you can’t check it, disclose this to the editor / author. Often the authors need to provide a better explanation to you, especially if this is your area.
  12. Don’t be afraid to reject papers. Often first-time reviewers write a very harsh review then proceed to accept the paper. This is hard on the editor. On the other hand, don’t be afraid to accept good papers. You will review papers that are quite good. It happens.
  13. On paper revisions, make sure the authors addressed your comments in the manuscript. Too often authors simply respond to the reviewer without changing the manuscript. Read all the reviews and check new parts of the manuscript. If your comments have been satisfied then accept the paper. If not then ask for another revision.

That’s all for now! Please post questions or comments and I will revise as appropriate.

WSIL folder access in the WNCG

Reference 1 Comment »

I’ve been getting alot of requests from WSIL members regarding access to the WSIL network folder from your desk in the WNCG (the previous post was for VPN remote access). Since you are accessing the network locally, the procedure is somewhat different. Below I show how to map the network drive for both Mac OS X and Win XP.

  • For Win XP: There are two ways that your network can be configured.
    1. Most members are using a PC that was pre-configured by the IT people at UT (i.e. if you were given the PC by Dr. Heath). When you log on to these computers (with your ENGR account) you are automatically connected to the ENGR network. Therefore, the network drive is local and already authenticated to you. To map the network drive go directly to step 5, substep 2 in this post (for some unknown reason, some computers enter \\file\coe\ece\groups\WSIL instead in the Folder box). You won’t be prompted to enter your username and password.
    2. If you are trying to connect your own PC to the network locally (e.g. if you want to plug the network cable into your laptop) you have to manually connect to the network. Follow the same procedure as step 1 above, but this time you will be prompted for a username and password. For the username enter ENGR\[UT EID].
  • For Mac OS X: To my knowledge, UT doesn’t supply Macintosh computers to WNCG students, therefore you are using a non-configured setup and must manually connect to the network drive with the following procedure.  Just follow step 5, substep 1 here to create your network drive on the desktop.

VPN for UT and ENGR access

Reference 3 Comments »

Within the last year, VPN access at UT has changed. Instead of independent ENGR VPN access, UT and ENGR accounts can be accessed under the same VPN. What follows is a step by step account of how to access the ENGR file server and the WSIL folder for both Windows XP and Mac OS X.

  1. Dowload and install the Cisco VPN client (both Mac OS X and WinXP are available) from the Bevoware link on UT Direct.
  2. Using this VPN client, connect to the ITS VPN server at vpn.its.utexas.edu.
  3. Enter your username and password as your UT EID and password respectively (note: this is the same way you login to UTDirect).
  4. Visit this page to verify that your VPN is active. If not active, see the troubleshooting guidelines on that page.
  5. Now we map the network drive of the WSIL folder.
    • To map network drives on Mac OS X go to the finder application, click the Go menu and select Connect to Server. The server name of the drive is smb://file.engr.utexas.edu/COE/ECE/Groups/ECE_WSIL entering ENGR as the domain, your UT EID as your username, and the password corresponding to your ENGR account.
    • On Win XP right click on My Computer and select Map Network Drive. Select the drive letter you want to access the network drive as, then type \\file.engr.utexas.edu\COE\ECE\Groups\ECE_WSIL in the Folder box. For the username enter ENGR\[UT EID] with your ENGR account password as the password.

For additional help on VPNs at UT, see the following: link-1, link-2